Last-call DoS/DoS Attack BCOP

Wed Mar 25 12:27:14 UTC 2015

Christopher Morrow <morrowc.lists at gmail.com> writes:

> 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).

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