Hail NANOGers! As most of you hopefully know, NANOG now has a BCOP Ad Hoc Committee and we are pushing forward with new BCOPs! http://nanog.org/governance/bcop We currently have three BCOPs in active development: eBGP configuration, shepherd Bill Armstrong Public Peering Exchange update, shepherd Shawn Hsiao Ethernet OAM, shepherd Mark Calkins All three of these nascent BCOPs will be presented in the BCOP Track on Monday: http://nanog.org/meetings/abstract?id=2348 We have also collected a list of Appeals (BCOPs that need to be written): http://bcop.nanog.org/index.php/Appeals If you would like to help out with any of these BCOPs (or others yet to be identified) please join the BCOP mailing list and reach out to the shepherd (if applicable of course): http://mailman.nanog.org/mailman/listinfo/bcop Our committee is brand new and we are still finding and smoothing wrinkles, etc. We would love your help in any capacity. As a BCOP shepherd or SME or just to point out potential pit falls or room for improvement, with the process, the wiki, a BCOP or anything at all really. This is a bottom-up, community led effort and it will only succeed with your help - join us in creating what I believe will be a vital and long-lasting institution! Cheers, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com
OK NANOGers, Some of us got the call to arms from Chris G email below and the NANOG BCOP Committee and now we are interested in generating DoS attack-related Best Common Practices (BCOP) appeal to serve the entire NANOG community. This document, as other BCOP appeals are expected to be as brief as possible and to the point in order to keep it practical and useful. The goal is to generate a set of best practices of what to do before/during/after a DoS/DDoS attack -- including what seems to have worked best and what hasn't. Time dedicated to this effort should extensive and participation can be non-real-time given that it can be done over email with no need for conference calls if desired. DoS and DDoS attacks have been a topic that have captured high interest from NANOGers based on the archived list topics and email threads. So, now is your time to help shape a NANOG BCOP Appeal on this topic. Please contact me off-list if you want participate by either sharing your experience, expertise or opinions towards generating a DoS Attack BCOP. Yardiel Fuentes yardiel@gmail.com twitter: #techguane On Jun 1, 2014, at 5:25 PM, Chris Grundemann wrote:
Hail NANOGers!
As most of you hopefully know, NANOG now has a BCOP Ad Hoc Committee and we are pushing forward with new BCOPs! http://nanog.org/governance/bcop
We currently have three BCOPs in active development:
eBGP configuration, shepherd Bill Armstrong Public Peering Exchange update, shepherd Shawn Hsiao Ethernet OAM, shepherd Mark Calkins
All three of these nascent BCOPs will be presented in the BCOP Track on Monday: http://nanog.org/meetings/abstract?id=2348
We have also collected a list of Appeals (BCOPs that need to be written): http://bcop.nanog.org/index.php/Appeals
If you would like to help out with any of these BCOPs (or others yet to be identified) please join the BCOP mailing list and reach out to the shepherd (if applicable of course): http://mailman.nanog.org/mailman/listinfo/bcop
Our committee is brand new and we are still finding and smoothing wrinkles, etc. We would love your help in any capacity. As a BCOP shepherd or SME or just to point out potential pit falls or room for improvement, with the process, the wiki, a BCOP or anything at all really.
This is a bottom-up, community led effort and it will only succeed with your help - join us in creating what I believe will be a vital and long-lasting institution!
Cheers, ~Chris
-- @ChrisGrundemann http://chrisgrundemann.com
Hello NANOGers, Following up on the below effort from last year, the DDoS/DoS Attack BCOP Draft document is ready for the last call 2-week period. After this period and unless notable objections are raised, the current document will be ratified as such. The current document can be found in the NANOG BCOP site -- link to current document found below: http://bcop.nanog.org/index.php/BCOP_Drafts Any additional community-wide comments or feedback in order to ensure quality documentation are not only very welcome but encouraged. Cheers, Yardiel Fuentes On Jul 2, 2014, at 6:48 PM, Yardiel D. Fuentes wrote:
OK NANOGers,
Some of us got the call to arms from Chris G email below and the NANOG BCOP Committee and now we are interested in generating DoS attack-related Best Common Practices (BCOP) appeal to serve the entire NANOG community.
This document, as other BCOP appeals are expected to be as brief as possible and to the point in order to keep it practical and useful.
The goal is to generate a set of best practices of what to do before/during/after a DoS/DDoS attack -- including what seems to have worked best and what hasn't. Time dedicated to this effort should extensive and participation can be non-real-time given that it can be done over email with no need for conference calls if desired.
DoS and DDoS attacks have been a topic that have captured high interest from NANOGers based on the archived list topics and email threads. So, now is your time to help shape a NANOG BCOP Appeal on this topic.
Please contact me off-list if you want participate by either sharing your experience, expertise or opinions towards generating a DoS Attack BCOP.
Yardiel Fuentes yardiel@gmail.com twitter: #techguane
On Jun 1, 2014, at 5:25 PM, Chris Grundemann wrote:
Hail NANOGers!
As most of you hopefully know, NANOG now has a BCOP Ad Hoc Committee and we are pushing forward with new BCOPs! http://nanog.org/governance/bcop
We currently have three BCOPs in active development:
eBGP configuration, shepherd Bill Armstrong Public Peering Exchange update, shepherd Shawn Hsiao Ethernet OAM, shepherd Mark Calkins
All three of these nascent BCOPs will be presented in the BCOP Track on Monday: http://nanog.org/meetings/abstract?id=2348
We have also collected a list of Appeals (BCOPs that need to be written): http://bcop.nanog.org/index.php/Appeals
If you would like to help out with any of these BCOPs (or others yet to be identified) please join the BCOP mailing list and reach out to the shepherd (if applicable of course): http://mailman.nanog.org/mailman/listinfo/bcop
Our committee is brand new and we are still finding and smoothing wrinkles, etc. We would love your help in any capacity. As a BCOP shepherd or SME or just to point out potential pit falls or room for improvement, with the process, the wiki, a BCOP or anything at all really.
This is a bottom-up, community led effort and it will only succeed with your help - join us in creating what I believe will be a vital and long-lasting institution!
Cheers, ~Chris
-- @ChrisGrundemann http://chrisgrundemann.com
Thank you all who have contributed your feedback, comments and discussion points towards the DDoS/DoS attack BCOP. I have updated the current version of the BCOP with the agreed upon feedback: http://bcop.nanog.org/index.php/BCOP_Drafts Since there have been good feedback for this BCOP. The committee decided to extend the "last-call period" for another two weeks to give ample chance to further feedback. So, it is not late for more comments, Yardiel Fuentes On Feb 27, 2015, at 11:16 AM, Yardiel D. Fuentes wrote:
Hello NANOGers,
Following up on the below effort from last year, the DDoS/DoS Attack BCOP Draft document is ready for the last call 2-week period. After this period and unless notable objections are raised, the current document will be ratified as such. The current document can be found in the NANOG BCOP site -- link to current document found below:
http://bcop.nanog.org/index.php/BCOP_Drafts
Any additional community-wide comments or feedback in order to ensure quality documentation are not only very welcome but encouraged.
Cheers,
Yardiel Fuentes
On Jul 2, 2014, at 6:48 PM, Yardiel D. Fuentes wrote:
OK NANOGers,
Some of us got the call to arms from Chris G email below and the NANOG BCOP Committee and now we are interested in generating DoS attack-related Best Common Practices (BCOP) appeal to serve the entire NANOG community.
This document, as other BCOP appeals are expected to be as brief as possible and to the point in order to keep it practical and useful.
The goal is to generate a set of best practices of what to do before/during/after a DoS/DDoS attack -- including what seems to have worked best and what hasn't. Time dedicated to this effort should extensive and participation can be non-real-time given that it can be done over email with no need for conference calls if desired.
DoS and DDoS attacks have been a topic that have captured high interest from NANOGers based on the archived list topics and email threads. So, now is your time to help shape a NANOG BCOP Appeal on this topic.
Please contact me off-list if you want participate by either sharing your experience, expertise or opinions towards generating a DoS Attack BCOP.
Yardiel Fuentes yardiel@gmail.com twitter: #techguane
On Jun 1, 2014, at 5:25 PM, Chris Grundemann wrote:
Hail NANOGers!
As most of you hopefully know, NANOG now has a BCOP Ad Hoc Committee and we are pushing forward with new BCOPs! http://nanog.org/governance/bcop
We currently have three BCOPs in active development:
eBGP configuration, shepherd Bill Armstrong Public Peering Exchange update, shepherd Shawn Hsiao Ethernet OAM, shepherd Mark Calkins
All three of these nascent BCOPs will be presented in the BCOP Track on Monday: http://nanog.org/meetings/abstract?id=2348
We have also collected a list of Appeals (BCOPs that need to be written): http://bcop.nanog.org/index.php/Appeals
If you would like to help out with any of these BCOPs (or others yet to be identified) please join the BCOP mailing list and reach out to the shepherd (if applicable of course): http://mailman.nanog.org/mailman/listinfo/bcop
Our committee is brand new and we are still finding and smoothing wrinkles, etc. We would love your help in any capacity. As a BCOP shepherd or SME or just to point out potential pit falls or room for improvement, with the process, the wiki, a BCOP or anything at all really.
This is a bottom-up, community led effort and it will only succeed with your help - join us in creating what I believe will be a vital and long-lasting institution!
Cheers, ~Chris
-- @ChrisGrundemann http://chrisgrundemann.com
On Mon, 23 Mar 2015 19:00:14 -0400 Yardiel D.Fuentes <yardiel@gmail.com> wrote:
Since there have been good feedback for this BCOP. The committee decided to extend the "last-call period" for another two weeks to give ample chance to further feedback.
So, it is not late for more comments,
Hi Yardiel, Nice work so far. A couple of additional ideas for you if you care to use them. If the attack is an infrastructure attack, say a routing interface that wouldn't normally receive or emit traffic from its assigned address except perhaps for network connectivity testing (e.g. traceroute) or control link local control traffic (e.g. local SPF adjacencies, BGP neighbors), you can "hide" those addresses, making them somewhat less easy to target by using something like unnumbered or unadvertised or ambiguous address space (e.g. RFC 1918). A second suggestion, if you want to add a reference to it is the UTRS project, which is a free community project that brings networks together for the purpose of exchanging RTBH announcements. We've recently enabled automated relay for IPv4 /32's that have a history of sole origination from a peer. This is another DDoS mitigation tool in the tool box that many may find helpful. More detail can be found here: <http://www.cymru.com/jtk/misc/utrs.html> John
John Kristoff <jtk@cymru.com> writes:
If the attack is an infrastructure attack, say a routing interface that wouldn't normally receive or emit traffic from its assigned address except perhaps for network connectivity testing (e.g. traceroute) or control link local control traffic (e.g. local SPF adjacencies, BGP neighbors), you can "hide" those addresses, making them somewhat less easy to target by using something like unnumbered or unadvertised or ambiguous address space (e.g. RFC 1918).
That comes at a cost, both operational/debugging and breaking pmtud. But if you don't care about collateral damage, setting the interface to admin-down stops attacks against it *cold*. Due to the drawbacks, I wouldn't consider this a good candidate for inclusion in a BCOP document. I have often thought there ought to be a companion series for Questionable Current Operational Practices, or maybe "desperate measures". I volunteer to write the article on "YOLO upgrades", wherein one loads untested software on equipment with no OOB, types "request system reboot", shouts "YOLO", and hits return. -r
On 3/24/15 5:27 AM, Rob Seastrom wrote:
John Kristoff <jtk@cymru.com> writes:
If the attack is an infrastructure attack, say a routing interface that wouldn't normally receive or emit traffic from its assigned address except perhaps for network connectivity testing (e.g. traceroute) or control link local control traffic (e.g. local SPF adjacencies, BGP neighbors), you can "hide" those addresses, making them somewhat less easy to target by using something like unnumbered or unadvertised or ambiguous address space (e.g. RFC 1918). That comes at a cost, both operational/debugging and breaking pmtud. But if you don't care about collateral damage, setting the interface to admin-down stops attacks against it *cold*.
Due to the drawbacks, I wouldn't consider this a good candidate for inclusion in a BCOP document.
I have often thought there ought to be a companion series for Questionable Current Operational Practices, or maybe "desperate measures". I volunteer to write the article on "YOLO upgrades", wherein one loads untested software on equipment with no OOB, types "request system reboot", shouts "YOLO", and hits return.
-r
You could have a whole blog series about redistributing BGP into IGPs. Or a "tricks and tips" section to add an allow any to all of your ACLs.
On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom <rs@seastrom.com> wrote:
John Kristoff <jtk@cymru.com> writes:
If the attack is an infrastructure attack, say a routing interface that wouldn't normally receive or emit traffic from its assigned address except perhaps for network connectivity testing (e.g. traceroute) or control link local control traffic (e.g. local SPF adjacencies, BGP neighbors), you can "hide" those addresses, making them somewhat less easy to target by using something like unnumbered or unadvertised or ambiguous address space (e.g. RFC 1918).
That comes at a cost, both operational/debugging and breaking pmtud.
being hidden stops pmtud only if the route isn't in the global table, right? There is not a requirement to do that if you can drop the traffic at your edge in other ways (filter). It's probably (arguably) better to not route to the space, but failing that (because you might like pmtud to work, or other error-type messaages to not be dropped by uRPFers) just rate-limit + filter at the edge seems like a decent compromise.
But if you don't care about collateral damage, setting the interface to admin-down stops attacks against it *cold*.
Due to the drawbacks, I wouldn't consider this a good candidate for inclusion in a BCOP document.
this is highly dependent upon your network design and topology though, right? By this i mean, if the device is an LSR and won't have IP traffic hit it's interfaces no harm no foul making them invisible. With some modern platforms you can even specify a single 'filter' and adjunct 'rate limiters' to be used across the entire device, right? This means you can permit traffic into your borders and let the device control access to itself with some relatively simple filters and rate-limits, so your access works, and pmtud works and dos attacks don't kill the device, just fill the interface to the device.
I have often thought there ought to be a companion series for Questionable Current Operational Practices, or maybe "desperate measures". I volunteer to write the article on "YOLO upgrades", wherein one loads untested software on equipment with no OOB, types "request system reboot", shouts "YOLO", and hits return.
YOLO
Christopher Morrow <morrowc.lists@gmail.com> writes:
On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom <rs@seastrom.com> wrote:
John Kristoff <jtk@cymru.com> writes:
If the attack is an infrastructure attack, say a routing interface that wouldn't normally receive or emit traffic from its assigned address except perhaps for network connectivity testing (e.g. traceroute) or control link local control traffic (e.g. local SPF adjacencies, BGP neighbors), you can "hide" those addresses, making them somewhat less easy to target by using something like unnumbered or unadvertised or ambiguous address space (e.g. RFC 1918).
That comes at a cost, both operational/debugging and breaking pmtud.
being hidden stops pmtud only if the route isn't in the global table, right? There is not a requirement to do that if you can drop the traffic at your edge in other ways (filter).
Yes, you can filter the incoming traffic at the edge of your network and not have to suffer the "ICMP fragmentation needed" messages coming from addresses that are either (a) 1918 and so likely to be dropped on the floor due to bogon filters, or (b) not in the routing table, and so likely to be dropped on the floor due to loose unicast rpf.
It's probably (arguably) better to not route to the space, but failing that (because you might like pmtud to work, or other error-type messaages to not be dropped by uRPFers) just rate-limit + filter at the edge seems like a decent compromise.
Sure, rate limiting potentially bad traffic to some multiple of normal background that doesn't cause you pain and protects you from disaster sounds like a plan. The other end of that telescope os COPP and we've been doing that for years...
But if you don't care about collateral damage, setting the interface to admin-down stops attacks against it *cold*.
Due to the drawbacks, I wouldn't consider this a good candidate for inclusion in a BCOP document.
this is highly dependent upon your network design and topology though, right? By this i mean, if the device is an LSR and won't have IP traffic hit it's interfaces no harm no foul making them invisible.
Yes, there are many corner cases where all sorts of creative solutions can be deployed. I'll bet the filters for your personal devices are different from the backbone filters at $DAYJOB too. John's statement was in the context of general advice to be included in a BCOP document and I felt compelled to say "whoa there".
With some modern platforms you can even specify a single 'filter' and adjunct 'rate limiters' to be used across the entire device, right?
This means you can permit traffic into your borders and let the device control access to itself with some relatively simple filters and rate-limits, so your access works, and pmtud works and dos attacks don't kill the device, just fill the interface to the device.
ayup
I have often thought there ought to be a companion series for Questionable Current Operational Practices, or maybe "desperate measures". I volunteer to write the article on "YOLO upgrades", wherein one loads untested software on equipment with no OOB, types "request system reboot", shouts "YOLO", and hits return.
YOLO
YOLO! -r
On Wed, 25 Mar 2015 08:27:14 -0400 Rob Seastrom <rs@seastrom.com> wrote:
John's statement was in the context of general advice to be included in a BCOP document and I felt compelled to say "whoa there".
My intent was for it to be taken as a DDoS mitigation response option, not as a general practice. John
On Wed, Mar 25, 2015 at 8:50 AM, John Kristoff <jtk@cymru.com> wrote:
On Wed, 25 Mar 2015 08:27:14 -0400 Rob Seastrom <rs@seastrom.com> wrote:
John's statement was in the context of general advice to be included in a BCOP document and I felt compelled to say "whoa there".
ok, that was my reaction as well.
My intent was for it to be taken as a DDoS mitigation response option, not as a general practice.
ok, I read over the bcop, I'm certain I wouldn't have used some of the words on the page, I'm certain that there are things suggested which I disagree with (mass filtering at your edge, if you are an ISP, all the time)... but I've not got the energy to poke too much more at this document :( and folk will find their balance anyway.
participants (6)
-
Chris Grundemann -
Christopher Morrow -
John Kristoff -
Maxwell Cole -
Rob Seastrom -
Yardiel D. Fuentes