Category: IPv6

Dual-stack exposures were the last topic Eric Vyncke and myself addressed in the IPv6 security webinar. They range from missing ip6tables on Linux hosts to unintentional split-tunnel VPNs and missing access classes on Cisco IOS devices.

One of the first arguments used by networking engineers living in IPv6 denial and trying to justify their stance is “IPv6 addresses are unreadable. We will never migrate to IPv6; it’s much easier to deal with IPv4 addresses.”

That’s absolutely true. If you use RFC 1918 addresses in a small(ish) network, the first two octets don’t change, and it’s easy to remember the remaining two numbers … but the unreadable IPv6 addresses just might change the way we approach network configuration and monitoring.

I wanted to figure out how to use IPv6 DAD proxy in PVLAN environments during my seaside vacations, and as I had no regular Internet access decided to download the whole set of IPv6 configuration guides while enjoying the morning cup of coffee in an Internet café. Opening the IPv6 First-Hop Security Configuration Guide was one of the most pleasant (professional) surprises I had recently.

One word summary: Awesome.

One of the significant challenges of IPv6 is the host address assignment and tracking (for logging/auditing reasons), more so if you use SLAAC or (even worse) SLAAC privacy extensions. Not surprisingly, Eric Vyncke and I spent significant time addressing this topic in the IPv6 Security webinar.

IPv6 source address spoofing should be old news – it’s no different from its IPv4 counterpart. Neighbor discovery exhaustion attack is an IPv6-only phenomenon enabled by huge IPv6 subnet sizes.

During the IPv6 Security webinar, Eric Vyncke described Cisco IOS mechanisms you can use to cope with both. Enjoy!

I was sitting next to a really nice security engineer during the fantastic dinner-in-a-wine-cellar @ Troopers 13 and as we started talking about security implications of ignoring IPv6, I was quickly able to persuade him that it's dangerous to pretend IPv6 doesn't exist and that even though you might choose not to deploy it, you still have to acknowledge it exists and take protective measures.

It’s always great fun to explain the dangers of ignoring IPv6 to a networking or security audience, and see some people muttering “oh, ****”

Just received an email from Trevor Warwick (Director, Cisco NOSTG Software Engineering, UK) on ipv6-ops mailing list (which you really should join if you plan to deploy IPv6) explaining the changes they made to IPv6 TCP MSS handling.

Kevin left a pretty valid comment to my Are you ready to change your security paradigm blog post:

I disagree that a compromised security zone is game over. Security is built in layers. Those host in a compromised security zone should be hardened, have complex authentication requirements to get in them, etc. Just because a compromised host in a security zone can get at additional ports on the other hosts doesn't mean an attacker will be more successful.

He’s right from the host-centric perspective (assuming you actually believe those other hosts are hardened), but once you own a server in a security zone you can start having fun with intra-subnet attacks.

IETF recently published RFC 6877 (464XLAT) describing a dual-translation mechanism that allows an IPv6 host (or CPE) in an IPv6-only access network to pretend it still has IPv4 connectivity. Why would one need a kludge ingenious solution like this? In a word: Skype.

For more details, watch the video explaining the need for 464XLAT and two typical use cases: Android handset and a CPE device (example: SOHO router with 3G uplink).

We learned how to deal with ARP and IP spoofing in IPv4 networks. Every decent switch has DHCP snooping, ARP protection, and IP source guard (or whatever the features are called), but validating source IPv6 addresses in security-conscious environments or public multi-access networks remains a major headache.

It would be pretty easy to solve the problem with a central controller, but IETF decided to go another way and developed yet another framework: Source Address Validation Improvements (SAVI). For more information, watch the following video from IPv6 Security webinar in which Eric Vyncke describes the intricacies of SAVI in great details.

It seems that most people not having a vested interest in status quo agree the socket API is broken. After all, why should every single application ever written have to deal with the idiosyncrasies of two address families?

Not surprisingly, the browser vendors got sick and tired of waiting for a fixed API or a standardized session layer (nothing happened in the last two decades) and decided to implement happy eyeballs – a simple mechanism that creates two TCP sessions (one over IPv4, another one over IPv6) and uses whichever one works better.

You might not have to deploy IPv6 in your network tomorrow (if you’re an ISP I sincerely hope you do), but that’s no excuse for not getting prepared for the eventual inevitable deployment (Tom Hollingsworth has way more to say on this topic).

Don’t believe in the “inevitable” part? Maybe you should spend some time with people who were running SNA and IPX networks two decades ago and living in blissful IP denial.

A heated debate on one of the IPv6 mailing lists (more about that later) contained a gem I simply have to share with you: The importance of IPv6 application testing from Apricot 2013. Enjoy!

One of my readers sent me an interesting question:

Are you aware of any studies looking at the effectiveness of IPv6 address allocation policies? I'm specifically interested in the affects of allocation policy on RIB/FIB sizes.

Well, we haven’t solved a single BGP-inflating problem with IPv6, so expect the IPv6 BGP table to be similar to IPv4 BGP table once IPv6 is widely deployed.

Sander Steffann, Iljitsch van Beijnum and Rick van Rein recently published an amazing IETF draft comparing IPv6-over-IPv4 tunneling mechanisms. If you’re even remotely interested in this topic, the draft is an absolute must-read (and if you want to know about other transitional mechanisms, check out this webinar).