Re: Last-call DoS/DoS Attack BCOP
-- > 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 - If a manager forces me to do this is it a requirement that I have to yell yolo? ;-) One day I'm going to write that into the test plan. I absolutely hate it when they do that... scott
Re: Last-call DoS/DoS Attack BCOP
On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom wrote: > > John Kristoff 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
AT&T BGP Operations in Miami, FL
Hello, Is there anyone from ATT BGP operations who can contact-me off list please for Miami location? I have an open ticket since early morning and a BGP session not exporting other transit ASNs, which were just working by the morning. Thank you. -- Patrick Tracanelli
Re: Last-call DoS/DoS Attack BCOP
On 3/24/15 5:27 AM, Rob Seastrom wrote: John Kristoff 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.
Re: Last-call DoS/DoS Attack BCOP
John Kristoff 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
