Category: security

The Facts and Fiction: BGP Is a Hot Mess blog post generated tons of responses, including a thoughtful tweet from Laura Alonso:

Is your argument that the technology works as designed and any issues with it are a people problem?

A polite question like that deserves more than 280-character reply, but I tried to do my best:

BGP definitely works even better than designed. Is that good enough? Probably, and we could politely argue about that… but the root cause of most of the problems we see today (and people love to yammer about) is not the protocol or how it was designed but how sloppily it’s used.

Laura somewhat disagreed with my way of handling the issue:

Every now and then a smart person decides to walk away from their competence zone, and start spreading pointless clickbait opinions like BGP is a hot mess.

Like any other technology, BGP is just a tool with its advantages and limitations. And like any other tool, BGP can be used sloppily… and that’s what’s causing the various problems and shenanigans everyone is talking about.

Just in case you might be interested in facts instead of easy-to-digest fiction:

I was listening to a nice podcast with Nick Buraglio discussing the recent BGP hijack SNAFU impacting Cloudflare (and their reaction) and while I usually totally agree with Nick, I think that he tried to be way too nice when saying (paraphrasing) “I think Cloudflare was a bit harsh - I would prefer a more community-oriented approach along the lines of how could we help you do your job better”

This is a guest blog post by Andrea Dainese, senior network and security architect, and author of UNetLab (now EVE-NG) and  Route Reflector Labs. These days you’ll find him busy automating Cisco ACI deployments.

Following the Ivan’s post about Firewall Ruleset Automation, I decided to take a step forward: can we always have up-to-date and clean firewall policies without stale rules?

The problem

We usually configure and manage firewalls using a process like this:

If you’ve been in networking long enough you’d probably noticed an interesting pattern:

• Some topic is hotly debated;
• No agreement is ever reached even though the issue is an important one;
• The debate dies after participants diverge enough to stop caring about the other group.

I was reminded of this pattern when I was explaining the traffic filtering measures available in private and public clouds during the Designing Infrastructure for Private Clouds workshop.

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.