nanog mailing list archives
Re: Last-call DoS/DoS Attack BCOP
From: Christopher Morrow <morrowc.lists () gmail com>
Date: Wed, 25 Mar 2015 00:49:22 -0400
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
Current thread:
- Re: Last-call DoS/DoS Attack BCOP Yardiel D . Fuentes (Mar 23)
- Re: Last-call DoS/DoS Attack BCOP John Kristoff (Mar 23)
- Re: Last-call DoS/DoS Attack BCOP Rob Seastrom (Mar 24)
- Re: Last-call DoS/DoS Attack BCOP Maxwell Cole (Mar 24)
- Re: Last-call DoS/DoS Attack BCOP Christopher Morrow (Mar 24)
- Re: Last-call DoS/DoS Attack BCOP Rob Seastrom (Mar 25)
- Re: Last-call DoS/DoS Attack BCOP John Kristoff (Mar 25)
- Re: Last-call DoS/DoS Attack BCOP Christopher Morrow (Mar 25)
- Re: Last-call DoS/DoS Attack BCOP Rob Seastrom (Mar 24)
- Re: Last-call DoS/DoS Attack BCOP John Kristoff (Mar 23)
- <Possible follow-ups>
- Re: Last-call DoS/DoS Attack BCOP Scott Weeks (Mar 24)
- RE: Last-call DoS/DoS Attack BCOP Chuck Church (Mar 25)