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

Decades ago I understood the intricacies of AAA on Cisco IOS. These days I wing it and keep throwing spaghetti at the virtual wall until something sticks and I can log in (after all, it’s all in a lab, and I’m interested in routing protocols not interactions with TACACS+ server).

If you’re experiencing similar challenges you might appreciate AAA Deep Dive on Cisco Devices by the one and only Daniel Dib.

It’s amazing how quickly you can deploy new functionality once you have a solid foundation in place. In his latest blog post Adrian Giacometti described how he implemented a security solution that allows network operators to block source IP addresses (identified by security tools) across dozens of firewalls using a bot listening to a Slack channel.

Would you be surprised if I told you we covered similar topics in our automation course? 😇

This is a guest blog post by Matthias Luft, Principal Platform Security Engineer @ Salesforce, and a regular ipSpace.net guest speaker.

A couple of months ago I had the pleasure to publish my first guest post here and, as to be expected from ipspace.net, it triggered some great discussion.

With this input and some open thoughts from the last post, I want to dive into a few more topics.

Dealing with protocols that embed network-layer addresses into application-layer messages (like FTP or SIP) is great fun, more so if the said protocol traverses a NAT device that has to find the IP addresses embedded in application messages while translating the addresses in IP headers. For whatever reason, the content rewriting functionality is called application-level gateway (ALG).

Even when we’re faced with a monstrosity like FTP or SIP that should have been killed with napalm a microsecond after it was created, there’s a proper way of doing things and a fast way of doing things. You could implement a protocol-level proxy that would intercept control-plane sessions… or you could implement a hack that tries to snoop TCP payload without tracking TCP session state.

Not surprisingly, the fast way of doing things usually results in a wonderful attack surface, more so if the attacker is smart enough to construct HTTP requests that look like SIP messages. Enjoy ;)

One of my readers is designing a layer-2-only data center fabric (no SVI interfaces on switches) with stringent security requirements using Cisco Nexus switches, and he wondered whether a host connected to such a fabric could attack a switch, and whether it would be possible to reach the management network in that way.

Do you think it’s possible to reach the MANAGEMENT PLANE from the DATA PLANE? Is it valid to think that there is a potential attack vector that someone can compromise to source traffic from the front of the device (ASIC) through the PCI bus across the CPU to the across the PCI bus to the Platform Controller Hub through the I/O card to spew out the Management Port onto that out-of-band network?

My initial answer was “of course there’s always a conduit from the switching ASIC to the CPU, how would you handle STP/CDP/LLDP otherwise”. I also asked Lukas Krattiger for more details; here’s what he sent me:

Post-quantum cryptography (algorithms resistant to quantum computer attacks) is quickly turning into another steaming pile of hype vigorously explored by various security vendors.

Christoph Jaggi made it his task to debunk at least some of the worst hype, collected information from people implementing real-life solutions in this domain, and wrote an excellent overview article explaining the potential threats, solutions, and current state-of-the art.

You (RFC 6919) OUGHT TO read his article before facing the first vendor presentation on the topic.

Peter Welcher identified the biggest network security hurdle faced by most enterprise IT environments in his comment to Considerations for Host-based Firewalls (Part 1) blog post:

I have NEVER found a customer application team that can tell me all the servers they are using, their IP addresses, let alone the ports they use.

His proposed solution: use software like Tetration (or any other flow collecting tool) to figure out what’s really going on:

One of the readers of the Considerations for Host-Based Firewalls blog post wrote this interesting comment:

Perhaps a paradigm shift is due for firewalls in general? I’m thinking quickly here but wondering if we perhaps just had a protocol by which a host could request upstream firewall(s) to open access inbound on their behalf dynamically, the hosts themselves would then automatically inform the security device what ports they need/want opened upstream.

Well, we have at least two protocols that could fit the bill: Universal Plug and Play and Port Control Protocol (RFC 6887).

This is a guest blog post by Matthias Luft, Principal Platform Security Engineer @ Salesforce, and a regular ipSpace.net guest speaker.

Having spent my career in various roles in IT security, Ivan and I always bounced thoughts on the overlap between networking and security (and, more recently, Cloud/Container) around. One of the hot challenges on that boundary that regularly comes up in network/security discussions is the topic of this blog post: microsegmentation and host-based firewalls (HBFs).