Skip to main content

Last Call Review of draft-ietf-grow-bgp-session-culling-04

Request Review of draft-ietf-grow-bgp-session-culling
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-09-25
Requested 2017-09-11
Authors Will Hargrave , Matt Griswold , Job Snijders , Nick Hilliard
I-D last updated 2017-09-25
Completed reviews Rtgdir Last Call review of -04 by Stig Venaas (diff)
Genart Last Call review of -04 by Brian E. Carpenter (diff)
Secdir Last Call review of -04 by Paul Wouters (diff)
Genart Telechat review of -05 by Brian E. Carpenter
Assignment Reviewer Paul Wouters
State Completed
Request Last Call review on draft-ietf-grow-bgp-session-culling by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 05)
Result Ready
Completed 2017-09-25
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the  security
area directors.  Document editors and WG chairs should treat  these
comments just like any other last call comments.

The summary of the review is Ready.

(note I am a tourist in the BGP area)

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.

This document has an empty Security Considerations section. As this BCP
document is basically a "cut yourself off the internet while doing maintenance"
I agree that there is basically nothing worse that could happen other then not
doing this RFC BCP and then leaking faulty BGP information onto the public
internet. One could add something like "don't forget to delete the firewall
rules afterwards" or "be sure to use ipv4 and ipv6 rules to prevent BGP leaks",
but then again this whole band aid RFC is meant for people who apparently have
shown an inability of properly executing RFC's anyway, and this document just
tries to convince them to only cut themselves, and not everyone else.