1 / 14

> Security and Robustness In Backbone Design

Learn about the importance of security and robustness in backbone design to protect data from threats such as nation-state snooping and physical disruptions. Explore topics like protocol security, physical redundancy, application layer filtering, and peering relationships.

williamsgreg
Download Presentation

> Security and Robustness In Backbone Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. > Security and Robustness In Backbone Design (no, really) Raven Alder

  2. > /home/raven/24601 • “I’m a consultant” • Security geek, backbone engineer • Two calls: planners, or something’s gone terribly wrong

  3. > Why you (might|should) care • Data transiting the Internet: not always secure • Private WANs are more shared than many people think at the carrier level • Ever-popular nation-state snooping • Or just a couple of dudes at DefCon (http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html) • Shared media? Shared data.

  4. > recursion • Protocol security (AAA stuff) • Physical redundancy (separate paths) • Use crypto (we mean it) • Plan for failure (no Dilbertean fallbacks) • Human element (but log everything) • Show me show me (OMG) • Ten years, one slide

  5. > increasingly challenging design specs • "we need this network to be resilient during undersea cable cuts, earthquake, tsunami, BGP updates, or military coups“ • Okay, then. • Don’t forget power and seizure. Hurricanes. September 11th. NANOG-worthy events.

  6. > large-scale outages and disaster recovery • Plan for things to go truly, epically wrong

  7. > airborne • Good: some different eyes than land lines • Bad: some different eyes than land lines • Differential timing attacks • Good: mobility • Bad: trackability? • Consider pre-emption before you buy

  8. > physical layer • Undersea cable cuts -- how many at once? No one (public) in the Mediterranean expected four. • Who makes your routers? Sure they’re not third party knockoffs? How many of you actually check MD5s? (How many of you still trust MD5s?)

  9. > application proxies inline cleaning up protocols • Improved resistance to protocol implementation tomfoolery • No help with protocol design tomfoolery, except maybe alerts • Good if you’re a VoIP provider concerned with SIP tricks, for example • Not so good with BGP

  10. > logistics and ethics of application layer filtering on backbone networks • Customer expectations of privacy • (consider who your customers are and their needs) • Expectations shape behaviour, which may not be the same as your design goals • People will end run your security if it’s not what they think it should be

  11. > filtering and monitoring • Increasingly intelligent and context-sensitive filtering • Picks out words and phrases, not just block list of sites • Many protocols, from IM to Web • Proxies not so uber-leet as you think • Consider why VPNs are permitted, and where

  12. > keep on routing in the free world? • Globalization – let’s talk manufacturing • Oh, and first world countries would never do this. Otherwise what would we need telco immunity for? Er. • Information sharing programs • Industrial espionage • Straight up BGP hijack • Quis custodet telcorum?

  13. > choose your peers wisely • Underestimated importance of good peering relationships • Understand where you are in the pecking order. (“The Art of Peering”, http://www.nanog.org/papers/playbook.doc) • Sadly, most telcos are still dumb about this, so currently you have to aim to outroute them.

  14. > questions • raven@oneeyedcrow.net

More Related