Category: Security

IPv6 security-focused presentations were usually an awesome opportunity to lean back and enjoy another round of whack-a-mole, often starting with an attacker using IPv6 Router Advertisements to divert traffic (see also: getting bored at Brussels airport) .

Rogue IPv6 RA challenges and the corresponding countermeasures are thus a mandatory part of any IPv6 security training, and Christopher Werny did a great job describing them in IPv6 security webinar.

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.