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.