Christoph Jaggi, the author of Ethernet Encryption webinar, published a new version of Ethernet Encryptor Market Overview including:

• Network standards and platforms
• Data plane encryption
• Control plane security
• Key- and system management
• Relevant approvals
• Vendors and products, including detailed feature support matrices.

Christopher Werny has tons of hands-on experience with IPv6 security (or lack thereof), and described some of his findings in the Practical Aspects of IPv6 Security part of IPv6 security webinar, including:

• Impact of dual-stack networks
• Security implications of IPv6 address planning
• Isolation on routing layer and strict filtering
• IPv6-related requirements for Internet- or MPLS uplinks

After discussing the basics of IPv6 security in the hands-on part of IPv6 security webinar webinar, Christopher Werny focused on the IPv6 trust model (aka “we’re all brothers and sisters on link-local").

Use the email sent by Randy Bush to RIPE routing WG mailing list every time a security researcher claims a technology with no built-in security mechanism is insecure (slightly reworded to make it more generic).

Lately, I am getting flak about $SomeTechnology not providing protection from this or that malicious attack. Indeed it does not.

One of my readers sent me an interesting pointer:

I just watched a YouTube video by a security researcher showing how a five line python script can be used to unilaterally configure a Cisco switch port connected to a host computer into a trunk port. It does this by forging a single virtual trunk protocol (VTP) packet. The host can then eavesdrop on broadcast traffic on all VLANs on the network, as well as prosecute man-in-the-middle of attacks.

I’d say that’s a “startling revelation” along the lines of “OMG, VXLAN is insecure” – a wonderful way for a security researcher to gain instant visibility. From a more pragmatic perspective, if you enable an insecure protocol on a user-facing port, you get the results you deserve¹.

While I could end this blog post with the above flippant remark, it’s more fun considering two fundamental questions.

While I liked reading the Where to Stick the Firewall blog post by Peter Welcher, it bothered me a bit that he used microsegmentation to mean security groups.

I know that microsegmentation became approximately as well-defined as cloud or SDN¹, but let’s aim our shiny lance ² at the nearest windmill and gallop away…

It took more than seven years to publish an obvious fact as an RFC: IPv6 extension headers are a bad idea (RFC 9098 has a much more polite title or it would never get published).

One of my readers sent me an age-old question:

I have my current guest network built on top of my production network. The separation between guest- and corporate network is done using a VLAN – once you connect to the wireless guest network, you’re in guest VLAN that forwards your packets to a guest router and off toward the Internet.

Our security team claims that this design is not secure enough. They claim a user would be able to attach somehow to the switch and jump between VLANs, suggesting that it would be better to run guest access over a separate physical network.

Decades ago, VLAN implementations were buggy, and it was possible (using a carefully crafted stack of VLAN tags) to insert packets from one VLAN to another (see also: VLAN hopping).

I heard about SRv6 when it was still on the drawing board, and my initial reaction was “Another attempt to implement source routing. We know how that ends.” The then-counter-argument by one of the proponents went along the lines of “but we’ll use signed headers to prevent abuse” and I thought “yeah, that will work really well in silicon implementations”.

Years later, Andrew Alston decided to document the state of the emperor’s wardrobe (TL&DR: of course SRv6 is insecure and can be easily abused) and the counter-argument this time was “but that applies to any tunnel technology”. Thank you, we knew that all along, and that’s not what was promised.

You might want to browse the rest of that email thread; it’s fun reading unless you built your next-generation network design on SRv6 running across third-party networks… which was another PowerPoint case study used by SRv6 proponents.

In case you missed it, there’s a new season of Lack of DHCPv6 on Android soap opera on v6ops mailing list. Before going into the juicy details, I wanted to look at the big picture: why would anyone care about lack of DHCPv6 on Android?

The requirements for DHCPv6-based address allocation come primarily from enterprise environments facing legal/compliance/other layer 8-10 reasons to implement policy (are you allowed to use the network), control (we want to decide who uses the network) and attribution (if something bad happens, we want to know who did it).

Patrik Schindler sent me his views on code quality and resulting security nightmares after reading the Cisco SD-WAN SQL Injection saga. Enjoy!

I think we have a global problem with code quality. Both from a security perspective, and from a less problematic but still annoying bugs-everywhere perspective. I’m not sure if the issue is largely ignored, or we’ve given up on it (see also: Cloud Complexity Lies or Cisco ACI Complexity).

Christoph Jaggi sent me a link to an interesting article describing security vulnerabilities pentesters found in Cisco SD-WAN admin/management code.

I’m positive the bugs have been fixed in the meantime, but what riled me most was the root cause: Little Bobby Tables (aka SQL injection) dropped by. Come on, it’s 2021, SD-WAN is supposed to be about building secure replacements for MPLS/VPN networks, and they couldn’t get someone who could write SQL-injection-safe code (the top web application security risk)?

After almost a decade of bickering and haggling (trust me, I got my scars to prove how the consensus building works), the authors of Operational Security Considerations for IPv6 Networks (many of them dear old friends I haven’t seen for way too long) finally managed to turn a brilliant document into an Informational RFC.

Regardless of whether you already implemented IPv6 in your network or believe it will never be production-ready (alongside other crazy stuff like vaccines) I’d consider this RFC a mandatory reading.

I was listening to an excellent container networking podcast and enjoyed it thoroughly until the guest said something along the lines of:

With Kubernetes networking policy, you no longer have to be a networking expert to do container network security.

That’s not even wrong. You didn’t have to be a networking expert to write traffic filtering rules for ages.

I love the recent Internet of Trash article by Geoff Huston, in particular this bit:

“Move fast and break things” is not a tenable paradigm for this industry today, if it ever was. In the light of our experience with the outcomes of an industry that became fixated on pumping out minimally viable product, it’s a paradigm that heads towards what we would conventionally label as criminal negligence.

Of course it’s not just the Internet-of-Trash. Whole IT is filled with examples of startups and “venerable” companies doing the same thing and boasting about their disruptiveness. Now go and read the whole article ;)