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