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 12:20:08
Nick Hilliard wrote :
Personally - and I say this as an IXP operator who has had yet another 
week-end ruined due to prolonged DDoS problems on an IXP
fabric - 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.

I'm with you here. I have never been an IXP operator myself, but I think it's a 
bad idea that IXPs themselves get involved in the blackholing business. I habe 
been very specific in the CBBC FAQ (1) that it was not something I thought IXPs 
should use.

It's not just DDoS that will be targeted here.

Correct. Although some blackholing by _participants_ in an IXP could be useful, 
for the layer 9 issues you mentioned earlier it makes total sense that the IXP 
itself would not be involved. Maybe a route-server operated by a completely 
independent third party.

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

I have to disagree. This drafts does more than to standardize a codepoint, it 
creates a community with global significance. If the draft was about 
standardizing the :666 part of it, I could support it (with the removal of 3.4).

As of RFC5635, I thought it was a step in the right direction. A draft that 
reserves 1 digit in the community for BCP38 control (including a "don't care" 
option) and some other of the remaining digits in the community for some other 
knobs regarding the reason for blackholing would be the way to go, IMHA.

Michel.

(1) http://arneill-py.sacramento.ca.us/cbbc/

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