Last-call DoS/DoS Attack BCOP
morrowc.lists at gmail.com
Wed Mar 25 04:49:22 UTC 2015
On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom <rs at seastrom.com> wrote:
> John Kristoff <jtk at 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.
More information about the NANOG