> security and robustness in backbone design (no, really) raven alder

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

Upload: delphia-melton

Post on 25-Dec-2015

217 views

Category:

Documents


2 download

TRANSCRIPT

> Security and Robustness In Backbone Design

(no, really)

Raven Alder

> /home/raven/24601

• “I’m a consultant”• Security geek, backbone engineer• Two calls: planners, or something’s gone

terribly wrong

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

> 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

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

> large-scale outages and disaster recovery

• Plan for things to go truly, epically wrong

> 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

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

> 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

> 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

> 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

> 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?

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