Category: Security

One of the rules of sane social media presence should be don’t ever engage with evangelists believing in a particular technology religion, more so if their funding depends on them spreading the gospel. I was called old-school networking guru from ivory tower when pointing out the drawbacks of TRILL, and clueless incompetent (in more polite words) when retweeting a tweet pointing out the realities of carbon footprint of proof-of-work technologies.

Interestingly, just a few days after that Bruce Schneier published a lengthy essay on blockchain and trust, and even the evangelists find it a bit hard to call him incompetent on security topics. Please read what he wrote every time someone comes along explaining how blockchains will save the world (or solve whatever networking problems like VTEP-to-MAC mappings).

A while ago we published a guest blog post by Christoph Jaggi explaining the high-level security challenges of most SD-WAN solutions… but what about the low-level details?

Sergey Gordeychik dived deep into implementation details of SD-WAN security in his 35C3 talk (slides, video).

TL&DW: some of the SD-WAN boxes are as secure as $19.99 Chinese webcam you bought on eBay.

One of the points David Gee, a guest speaker in Spring 2019 Building Networking Automation Solutions online course, and Christoph Jaggi touched on in their interview was the security of network automation solutions (see also: automated workflows and hygiene of network automation).

What are the security risks for automation?

Security is an approach, not an afterthought.

A friend of mine told me about a “VXLAN is insecure, the sky is falling” presentation from RIPE-77 which claims that you can (under certain circumstances) inject packets into VXLAN virtual networks from the Internet.

Welcome back, Captain Obvious. Anyone looking at the VXLAN packet could immediately figure out that there’s no security in VXLAN. I pointed that out several times in my blog posts and presentations, including Cloud Computing Networking (EuroNOG, September 2011) and NSX Architecture webinar (August 2013).

Here’s another interesting talk from RIPE77: Routing Attacks in Cryptocurrencies explaining how BGP hijacks can impact cryptocurrencies.

TL&DR: Bitcoin is not nearly decentralized enough to be resistant to simple and relatively easy BGP manipulations.

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

After publishing the Manual Work Is a Bug blog post, I got this feedback from Michele Chubirka explaining why automating changes in your network also increases network security:

A team of IPv6 security experts I highly respect (including my good friends Enno Rey, Eric Vyncke and Merike Kaeo) put together a lengthy document describing security considerations for IPv6 networks. The document is a 35-page overview of things you should know about IPv6 security, listing over a hundred relevant RFCs and other references.

No wonder enterprise IPv6 adoption is so slow – we managed to make a total mess.

After figuring out how packet forwarding really works within AWS VPC (here’s an overview, the slide deck is already available to ipSpace.net subscribers) the next obvious question should be: “and how do I integrate a network services device like a next-generation firewall I have to use because $securityPolicy into that environment?”

Please don’t get me started on whether that makes sense, that’s a different discussion.

Christer Swartz, an old-time CCIE and occasional guest on Software Gone Wild podcast will show you how to do it with a Palo Alto firewall during my Amazon Web Services Networking Deep Dive workshop on June 13^th in Zurich, Switzerland (register here).

Not long after I published the blog post arguing against physical appliances, Oven wrote a very valid comment: "But then you'd have 20 individual systems to manage, add licenses to for additional features, updates etc."

Even though the blog post (and the comment) was written in 2013, not much has changed in the meantime.

One of my readers sent me a container security question after reading the Application Container Security Guide from NIST:

We are considering segregating dev/test/prod environments with bare-metal hardware. I did not find something in the standard concerning this. What should a financial institution do in your opinion?

I am no security expert and know just enough about containers to be dangerous, but there’s a rule that usually works well: use common sense and identify similar scenarios that have already been solved.