Last Call Review of draft-ietf-grow-blackholing-00

Request Review of draft-ietf-grow-blackholing
Requested rev. no specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-07-04
Requested 2016-06-23
Authors Thomas King, Christoph Dietzel, Job Snijders, Gert Doering, Greg Hankins
Draft last updated 2016-06-30
Completed reviews Genart Last Call review of -00 by Russ Housley (diff)
Genart Telechat review of -02 by Russ Housley (diff)
Secdir Last Call review of -00 by Paul Hoffman (diff)
Opsdir Last Call review of -00 by Susan Hares (diff)
Rtgdir Early review of -00 by Susan Hares (diff)
Assignment Reviewer Paul Hoffman 
State Completed
Review review-ietf-grow-blackholing-00-secdir-lc-hoffman-2016-06-30
Reviewed rev. 00 (document currently at 03)
Review result Has Issues
Review completed: 2016-06-30


This draft, "BLACKHOLE BGP Community for Blackholing", describes a new 

optional BGP community with the specific semantics of "please blackhole 

this traffic for me". The idea is to have a single common community 

instead of all the ad hoc communities that ISPs have created for this 


The beginning of the security considerations section is daunting in that 

it says, in essence, "BGP has no authentication, so injecting dangerous 

messages is trivial; thus this new dangerous community is not a 

problem". It then goes on to say "and this new community can be used as 

a DoS by your downstream peers because they can tell you lies, but you 

were already susceptible to those lies". And then "and this can be used 

for CPU exhaustion against you if you're not careful" without saying how 

to be careful.

There are currently two active threads on ietf@ about security 

implications of this draft. There are questions about whether this draft 

lacks enough specificity to prevent CPU exhaustion attacks even from 

well-meaning peers, whether it should be standards track given that it 

is underspecified, whether it should suggest that IXPs should implement 

it, and other questions seem to be coming up.

I think that this document *might* be OK as an Informational RFC if 

there is more discussion about how to prevent a CPU exhaustion attack 

for recipients and more MUSTs instead of SHOULDs for what other 

communities need to be applied to these messages.

--Paul Hoffman