IPv6 on Insinuator.net - Bold Statements

A Brief History of the IPv4 Address Space

Mon, 26 Aug 2019 00:00:00 +0000

This is meant to be the first part of a 3-part series discussing the space & types of IP addresses, with a particular focus on what has changed between IPv4 and IPv6. In this first post I’ll take the audience through a historical tour of some developments within the IPv4 address space.

In a second part I’ll discuss the properties of different types of addresses from a routing and from a security perspective, both in the IPv4 and in the IPv6 space. In the third part we’ll look at the implications of deploying IPv6 in certain networks based on those differences, e.g. “how to handle ACLs and IP address based log analysis approaches in a dual-stack network where systems have one RFC 1918 IPv4 address and multiple IPv6 GUAs?” (for specific reasons the latter two parts might be published on another medium though). In any case let’s start with a brief history of IPv4. The goal here is to understand how we got to the state that we have today.

IPv6 Surveys / Application Space

Sun, 30 Jun 2019 00:00:00 +0000

In some organizations we work with a certain state of IPv6 deployment has been reached in the interim which includes, among others, the following aspects:

the network infrastructure is IPv6-enabled (incl. interface addressing, routing [protocols] and the like).
parts of supporting services (security functions, monitoring, system management) include IPv6 in a proper way.
3rd party providers have been contractually obliged to deliver their services in an “IPv6-enabled” mode (as opposed to only being “IPv6-capable” which was the standard requirement in many RFIs during earlier years).

It might then happen that networking people (who often are the initial motivators for deploying IPv6) in such organizations are stating, when asked about IPv6: “it’s [mostly] done”.
Point is that, alas, this does not necessarily mean that a single service or application is *actually using* IPv6, so while the above certainly constitutes an achievement it might not even be halfway through.

IPv6 Properties of Windows Server 2019 / Windows 10 (1809)

Wed, 12 Jun 2019 00:00:00 +0000

In this post I’ll cover some properties of the Windows Server 2019 IPv6 stack. It is an update of a similar post I wrote on the IPv6 properties of Server 2016 a while ago.

For this reason I will mostly look at the same properties I did at the time (read: at times without providing too much technical background information; that can be found in the other post) and I’ve hence performed the same types of practical tests.

The Week in Review #RIPE78

Sun, 26 May 2019 00:00:00 +0000

This week Chris and I participated in the RIPE 78 meeting in Reykjavík. Being part of the group was fun as always and we had quite some interesting conversations with peers from (not only) the IPv6 community.
Big thanks to the RIPE NCC team for the smooth organization and for taking care of us!

In this post I’ll provide some notes on talks I found particularly interesting, plus links to our own contributions.

IPv6 Security for Enterprise Organisations @ #RIPE78

Fri, 17 May 2019 00:00:00 +0000

Chris and I will give a tutorial on the above topic at next week’s RIPE Meeting in Reykjavík. In this post (actually this will probably become a small series of posts) I’ll try to summarize some thoughts on IPv6 security in enterprise environments in 2019.

We’re going to cover three main areas:

Why IPv6 Is Different, Security-wise
Traffic Filtering in IPv6 Networks
IPv6 Security in L2 Networks / First Hop Security et al.

Let’s start with the first item. In real-life scenarios the security of “a protocol” – IPv6 can rather be considered a “protocol family” which includes helper protocols like ICMPv6 and MLD (which in turn is implemented by means of ICMPv6 messages) and potentially others like DHCPv6 – might depend on a number of factors:

#TR19 Next Generation Internet (NGI) Summaries

Thu, 02 May 2019 00:00:00 +0000

This blogpost contains summaries of talks from this year’s TROOPERS19 Active Directory Security Track.

Microsoft IT (Secure) Journey to IPv6-Only

Veronika McKillop, Network Architect, Cloud and Connectivity Engineering (CCE)

The speaker, Veronika McKillop, working at Microsofts network infrastructure services, has given a talk about the process of switching a company network from IPv4 to IPv6-only.

Within the talk the following topics were introduced: Dual Stack, Drivers for IPv6, Status of IPv6 in Networks and Security in IPv6 Networks. The talk covers the reasons why a company would like to switch from IPv4 to IPv6. Technics like NAT64 and DNS64 are introduced. The requirements to software and especially drivers to work in IPv6 environments are described. Also the problems to switch from IPv4 to IPv6-only in heterogeneous networks are addressed.

IPv6 Address Management / The “External” Flag

Fri, 22 Feb 2019 00:00:00 +0000

We’re regularly asked to review IPv6 address plans from different organizations and I’d like to share some reflections from such a process currently happening. I’ve discussed a few aspects of IPv6 address planning before; those readers interested please see this post which contains some references.

The organization in question is headquartered in Germany, has ~60K employees and a number of subsidiaries in European countries. They belong to a “traditional industry sector” (so they’re not an “Internet company”, even though they – as the majority of large organizations right now – strive to be one in a few years ;-).

IPv6 Security in an IPv4-only Environment

Wed, 20 Feb 2019 00:00:00 +0000

Starting a post, in 2019, with a mention of sth being “IPv4-only” somewhat hurts ;-), but here we go. Recently Manel Rodero from Barcelona asked me the following question on Twitter:

In this post I’ll try to discuss some inherent aspects of that question and ofc I’ll try to provide a response to it, too ;-).

Let’s first think about the main IPv6-related risks (= threats put into a context of relevance) in an “environment [that] is only IPv4”. While some of you might scratch your heads “what IPv6 threats could there be in an IPv4 setting?” I’m tempted to scratch my head: “what could be the reasons to run an university network without IPv6 these days, or to use BIND?” (which I have a strong opinion on, see here or here). But I disgress. More seriously the main reason for the question can be broken down to:

Some Notes on the IPv6 Properties of the Wireless Network @ Cisco Live Europe

Sun, 03 Feb 2019 00:00:00 +0000

Some years ago Christopher wrote two posts (2016, 2015) about the IPv6-related characteristics of the WiFi network at Cisco Live Europe. To somewhat continue this tradition and for mere technical interest I had a look at some properties of this year’s setting.

There were two SSIDs of interest: a dual-stacked one (“CiscoLive2019”) and one with v6-only plus NAT64 (“CL-NAT64”). For some background on the underlying infrastructure components you might look at this thread by Nicolas Darchis from the NOC or at this tweet from Dominik Pickhardt. Some stats on IPv6 usage at CLEUR can be found here.

IPv6 Talks & Publications

Thu, 10 Jan 2019 00:00:00 +0000

At first a very happy new year to everybody!

While thinking about the agenda of the upcoming Troopers NGI IPv6 Track I realized that quite a lot of IPv6-related topics have been covered in the last years by various IPv6 practitioners (like my colleague Christopher Werny) or researchers (like my friend Antonios Atlasis). In a kind of shameless self plug I then decided to put together of list of IPv6 talks I myself gave at several occasions and of publications I (co-) authored. Please find this list below (sorted by years); you can click on the titles to access the respective documents/sources.
I hope some of this can be of help for one or the other among you in the course of your own IPv6 efforts.
Cheers,

#TR18 Next Generation Internet (NGI) Summaries

Fri, 23 Mar 2018 00:00:00 +0000

This blogpost contains summaries of talks from this year’s TROOPERS18 Next Generation Internet Event.

NGI Keynote by Graeme Neilson

Before his infosec career Graeme was a street performer, then security researcher, now he calls himself a defender. The talk was built around the following sentence: “The infosec industry and community have completely failed to create meaningful change in the behavior of people”.

The following example is a resume of how hacking worked from 1988 to 2017:

Let’s talk about RFC 6980

Fri, 01 Dec 2017 00:00:00 +0000

Following my work with the FreeBSD implementation of RFC 6980 I was happy to present my work at last week’s DENOG 9 meeting.
To make it available to anyone who did not meet me there and go into some more detail that would have exceeded the boundaries of the talk, I will cover the topic here.

After the preceding work on Windows Server 2016 and the FreeBSD testing, as a Linux user, lover and administrator, I of course wanted to take a look at how different Linux systems complied with the RFC 6980 standard.

Why It Might Make Sense to Use IPv6 in Enterprise Infrastructure Projects

Fri, 10 Nov 2017 00:00:00 +0000

Looking at IPv6 deployment graphs like this one it becomes clear that IPv6 still is not widely deployed in enterprise space (the reason for the apparent oscillation in that curve is the difference between working days – where people use their office computers – and weekend where they preferably use their smartphones or their home equipment connected by means of broadband networks).

There’s a number of good reasons for this (in a nutshell: the overall IPv6 architecture is oriented around, and benefits, the decoupling of mostly autonomous, self-organized endpoints from a well-managed/provider-managed network infrastructure which isn’t exactly the operations model many large enterprise organizations have in mind for their networks. also you might have a look at these slides from RIPE74 to understand some of the reluctance to deploy IPv6 in certain companies).

Position Paper on an Enterprise Organization’s IPv6 Address Strategy

Mon, 09 Oct 2017 00:00:00 +0000

A while ago I wrote a short paper laying out options for an enterprise organization to get global IPv6 address space from the RIPE NCC, discussing the advantages and disadvantages of different approaches. As I think the topic may be of interest for others, too, I’ve distilled an anonymized version. It can be found here. I hope some of you find it useful.

Cheers, Enno

RIPE IoT Roundtable Meeting / Balanced Security for IPv6 CPE Revisited

Fri, 29 Sep 2017 00:00:00 +0000

Last week I had the pleasure to participate at the first RIPE IoT Roundtable Meeting in Leeds (thanks! to Marco Hogewoning for organising it). It was a day with many fruitful discussions. I particularly enjoyed Robert Kisteleki‘s talk on RIPE NCC’s own design & (security) process considerations in the context of RIPE Atlas (at TR17 NGI there was an intro to Atlas, too).
In this post I’d like to quickly lay out the main points of my own contribution on “Balanced Security for IPv6 CPE Revisited” (the slides can be found here).

An Update of PenTesting Tools that (do not) Support IPv6

Tue, 19 Sep 2017 00:00:00 +0000

As you may remember, back in 2014 we published a whitepaper (compiled by Antonis Atlasis) on the support of IPv6 in different pentesting tools. This is almost three years ago and we thought it is time for an update. In short not much has changed. Most of the tools which didn’t support IPv6 are still not supporting it or haven’t got any update since then.
This post will cover the tools where we could identify some progress on supporting IPv6.

IPv6 RA Flags, RDNSS and DHCPv6 Conflicting Configurations Revisited

Mon, 17 Jul 2017 00:00:00 +0000

As you may know, we published a whitepaper discussing the behavior of different operating systems once they receive IPv6 configuration parameters from different sources two years ago. At that time, the results were quite a mess. We were curious whether the situation is still so “dire” like two years ago. We fired up the lab, updated the tested operating systems and performed the tests again.

To summarize, at least in scenarios were only one router is involved, the results look way more consistent (even cross operating system) then two years ago. So we made progress on this front. Unfortunately, as soon as a second router is introduced into the segment it gets messy and the operating systems do show inconsistent behavior.

Local Packet Filtering with IPv6

Thu, 06 Jul 2017 00:00:00 +0000

Just recently we discussed IPv6 filter rules for NIC-level firewalls (in a virtualized data center) with a customer. I’d like to take this as an opportunity to lay out potential approaches for local packet filtering of IPv6, which in turn might somewhat depend on the address configuration strategy chosen for the respective systems (for the latter you may refer to this post or to this talk from the Troopers NGI event).

Some of this has already been discussed in RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls but that document is from 2007 and things may have changed in the interim.
Let’s start with a quick look at the traffic which might be of interest. We will take a server perspective here, read: which types of IPv6 traffic might have to be accepted by a host/NIC firewall in order to support proper operations? I will discuss the following, with a focus on the implications of filtering them locally:

Testing RFC 6980 Implementations of FreeBSD

Fri, 23 Jun 2017 00:00:00 +0000

Following Enno’s research on “Testing RFC 6980 Implementations with Chiron“, we decided to redo the experiment with FreeBSD targets.

The lab setup was very similar:

A Cisco Catalyst 3560 switch running the software “C3560c405ex-UNIVERSALK9-M” version 15.2(2)E4 connecting
A Linux based attacker system running Chiron and
A FreeBSD target system, running different OS versions and configurations and
A Linux based laptop running a control script that remotely performed the necessary tasks on the two machines mentioned above

The main question was: Would the impact on the target system and the possible attacks that were observed with the Windows Server 2016 victim be reproducible on other operating systems? Or would those behave totally differently?

RIPE74 / Why IPv6 Security Is So Hard

Fri, 12 May 2017 00:00:00 +0000

I’m on my way back from the RIPE74 meeting in Budapest. It was a great event: quite a few nice technical talks in the plenary, productive working group meetings and some really good hallway discussions.
Big thanks to the RIPE NCC team for the smooth organization and for taking care of us!

Here’s some stuff I found particularly interesting:

Andrew Alston’s take on “Anti-Shutdown Policies” (slides and video incl. extensive mic discussion)
Philip & Maximilian from Freifunk Rheinland on their efforts (slides, video)
Friso Feenstra on “That’s Why Rabobank Implemented IPv6” (slides, video) plus some insight into their address planning (slides, video)
BCOP work on “IPv6 Prefix Assignments/Prefix Delegation” and “IPv6 Assignments for Hosting Providers“
Jerry Lundström‘s DNS Replay Tool (slides, video, code)
Jan Žorž (supported by Sander Steffann) on NAT64 testing (slides, video, code)

These were my own contributions:

One Step Closer – RDNSS (RFC 8106) Support in Windows 10 Creators Update

Mon, 08 May 2017 00:00:00 +0000

Good Afternoon,

It is a pleasant surprise for many (us included) that Microsoft implemented support for the RDNSS (RFC 8106) option in Router Advertisements beginning with the Windows 10 Creators Update. Interestingly, I wasn’t able to find any official documents from Microsoft stating this. As we are involved in a lot of IPv6 related projects for our customers, the lack of RDNSS support for Windows and DHCPv6 for Android is a major pain point when implementing IPv6 in mixed client segments, as you need to implement both mechanisms to ensure that all clients do get the relevant network parameters. I won’t beat on the dead horse, but Microsoft’s decision is a huge step in the right direction and one can hope that one day Google finds a “compelling use case” to implement at least stateless DHCPv6 for Android.

Testing RFC 6980 Implementations with Chiron

Sat, 11 Mar 2017 00:00:00 +0000

In the recent post on the IPv6 properties of the latest MS Windows versions I announced another one providing details on the RFC 6980 related testing I had performed. So here we go.

When doing IPv6 security testing there’s mainly four toolkits which can be used:

Antonios Atlasis‘ Chiron
Marc Heuse’s THC-IPV6
Fernando Gont‘s IPv6 Toolkit
Scapy (whose IPv6 capabilities are, afaik, mainly maintained by Guillaume Valadon. some tutorial on IPv6 packet crafting with scapy can be found here).

Each of them has specific strenghts & limits, which will not be discussed here. For the testing I performed I chose Chiron as it has the most powerful options when it comes to IPv6 extension headers and fragmentation.

IPv6 Properties of Windows Server 2016 / Windows 10

Mon, 30 Jan 2017 00:00:00 +0000

In this post we’ll take a detailed look at the properties of the Windows Server 2016 IPv6 stack.
I perform(ed) this exercise for several reasons:

Server 2016 is the latest OS released by Microsoft so this might give an indication as for their plans & strategy when it comes to supporting certain specifications.
(here you may keep in mind that the ~50 IETF meetings having passed since the publication of RFC 2460 provided ample opportunity for creative minds to come up with ever new ideas for “enhancing” IPv6, without too much real-life feedback/reality checks from enterprise space though, as simply not many of such organizations have deployed it at scale… or are incentivized to send their employees to week-long meetings in expensive hotels on other continents twice a year…).
as I laid out in this post the configuration approach an organization takes for their servers might depend on the support of specific features.
obviously for both IPv6 planning and operations it might be helpful to understand the respective behavior of individual operating systems (which is why we researched stuff like this or this in the past).
many years ago Microsoft published white papers with details as for the TCP/IP parameters of their OSs (incl. stuff like registry parameters to control it etc.) but I’m not aware of such a document for Server 2016 or Windows 10. I hence hope this post can somewhat contribute to public knowledge of the intricacies of their latest IPv6 stack.

Version

IPv6 Configuration Approaches for Servers

Wed, 21 Dec 2016 00:00:00 +0000

In this post I’ll discuss configuration approaches for systems which usually have been configured with “static” IP parameters in the IPv4 age/context (like servers in data centers). When it comes to IPv6 there are more options and we’ll have a look at their implications and potential advantages/disadvantages.

From my perspective there’s mainly four possible approaches which we see being implemented or considered in our (predominantly enterprise) customer space. Before we have a closer look at those let’s quickly write down requirements that the involved planners or sysadmins might have in mind when it comes to provisioning the systems in question. Some of those requirements might seem obvious but it could still make sense to note them for the discussion to follow. These might include:

Some Notes from the Lab – BlackNurse in the IPv6 Era

Mon, 05 Dec 2016 00:00:00 +0000

Since BlackNurse was released on 10th of November, we asked ourselves whether this problem does also apply to ICMPv6 traffic. To answer this question, Christian Tanck (one of our students) build a lab with several firewall appliances. Kudos to him for testing and the following blog post.

Intro

On 10^(th) of November, 2016 the TDC Security Operations Center in Denmark published the BlackNurse Denial of Service Attack Report as an PDF download on their website and a blog post written by Erik Hjelmvik from NETRESEC. He was involved in the project by helping with the analysis of packet dumps, testing different systems, with ideas for test scenarios and at least inspired me with his blog post on how to build a test lab described later in this post. The attack on its own was discovered by the TDC analysts Kenneth B. Jørgensen and Lenny Hansson.

IPv6 Source Address Selection

Wed, 02 Nov 2016 00:00:00 +0000

As we all know an IPv6 enabled host can have multiple addresses. In order to select a source address for a to-be established outbound connection, operating systems implement a source address selection mechanism that evaluates multiple source address candidates and selects the (potentially) best candidate. Criteria for this selection are defined in RFC6724 (which obsoletes RFC 3484).

To find out if there are differences as for the way various OSs implement this mechanism we performed a little study whose results can be found in this whitepaper. Those differences might be particularly relevant for data center environments or enterprise networks with a variety of heterogeneous client operating systems. If interested in IPv6 in enterprise networks this training that I’ll give in some weeks might be worth attending for some of you, too.

Follow-Up on CVE-2016-1409 – IPv6 NDP DoS Vulnerability

Sun, 21 Aug 2016 00:00:00 +0000

This is a guest post from Jed Kafetz.

After seeing Christopher’s post I decided to create a proof using GNS3 and Virtualbox.
The aim is to perform the exact attacking using Antonios Atlasis’ Chiron tools and run a Wireshark packet capture to prove the hop limit drops below 255.

The following topology is used in GNS3:

The routers used are Cisco C372 and the machine labled Ubuntu is running 14.04 LTS Ubuntu Desktop, default installation. F0/0 is on the right and F0/1 is on the left.

IPv6 & Threat Intelligence

Fri, 03 Jun 2016 00:00:00 +0000

Tomorrow, I will join a meeting where I’m expected to contribute, amongst others, to a discussion on the impact of IPv6 on threat intelligence. To prepare for that I started putting together some thoughts & ideas on the topic, and I even thought I might share this in a post (the one you read right now ;-), not least to, maybe, stimulate a discussion.

I don’t know much about threat intelligence so it might happen that, at times, I use some misguided terms or I expose a (too) naïve understanding of some concepts. Happy to be corrected in one way or another.

CVE-2016-1409 – IPv6 NDP DoS Vulnerability in Cisco Software

Mon, 30 May 2016 00:00:00 +0000

Dear readers,

As you may have already noticed, Cisco released an urgent security advisory describing an IPv6 Neighbor Discovery DoS Vulnerability in several flavors of Cisco’s operating systems. Currently IOS-XR, XE and NX-OS are affected while ASA and “classic” IOS are under investigation. At first glance, it might look like yet another IPv6 DoS vulnerability. Looking closer, Cisco is mentioning an unauthenticated, remote attacker due to insufficient processing logic for crafted IPv6 NDP packets that are sent to an affected device. Following the public discussion about the vulnerability, it seems that these packets will reach the, probably low rate-limited, LPTS filter/queue on IOS XR devices “crowding” out legitimate NDP packets resulting in a DoS for IPv6 traffic, or in general a high CPU load as these packets will be processed by the CPU. More details are currently not available, but this might indicate the affected systems aren’t doing proper message validation checks on NDP packets (in addition to the LPTS filter/queue problem).

The Beauty of IPv6 Link-Local Addressing. Not

Sat, 28 May 2016 00:00:00 +0000

In November 2014, after quite some controversy in the IETF OPSEC working group (for those interested look at the archives), the Informational RFC 7404 “Using Only Link-Local Addressing inside an IPv6 Network” was published. It is authored by Michael Behringer and Eric Vyncke and discusses the advantages & disadvantages of an approach using “only link-local addresses on infrastructure links between routers”.

So it’s (merely) about “infrastructure links” which some people call “transit networks” or “point to point” (ptp) links. I’m aware that there might be subtle differences between all these, depending on your specific use of the terms. Still I assume that most readers will have an understanding of what types of links are in focus of the RFC, and subsequently of this post.

Security Assessment of Microsoft DirectAccess

Wed, 06 Apr 2016 00:00:00 +0000

A talk about DirectAccess (an IPv6-only VPN solution) was given by our colleague Ali Hardudi during IPv6 summit. Ali has recently finished his master thesis on this topic.

The DirectAccess VPN technology was introduced by Microsoft starting from Windows server 2008. It allows users remotely, seamlessly and securely connect to their internal network resources without a need to provide user credentials, which is done using different technologies such as Windows domain group policies.

Anonymization IPv6 in PCAPs – Challenges and Wins

Tue, 05 Apr 2016 00:00:00 +0000

Jasper Bongertz is a Senior Technical Consultant at Airbus Defence and Space CyberSecurity. He is focusing on IT security, Incident Response and Network Forensics.
During the IPv6 summit on Troopers16 he had given a talk on anonymization IPv6 in PCAPs and presented his new tool.

Sometimes you need to share your packet capture files (PCAPs), but distributing them involves a risk of exposing the confidential information. To avoid this, you must sanitize your PCAPs. The goal of sanitization is to remove the critical details but keep enough information for the PCAP to still be useful. The original-to-sanitized ratio is based on your goals.

draft-vyncke-pim-mld-security

Mon, 04 Apr 2016 00:00:00 +0000

Right now, I’m in Buenos Aires for IETF95 where, amongst others, an Internet-Draft authored by Eric Vyncke, Antonios Atlasis and myself will be presented (and hopefully discussed) in two working groups. In the following I want to quickly lay out why we think this is an important contribution.

As some of you may remember about two years ago we started an internal research project on the IPv6 “helper procotol” Multicast Listener Discovery (MLD) and its security properties. One outcome of this research project was Jayson Salazar‘s excellent thesis on the topic (the full document can be found here), another outcome were the related talks we gave at DeepSec 2014 and at Troopers15.

Advanced IPv6 Network Reconnaissance

Sun, 03 Apr 2016 00:00:00 +0000

Fernando Gont, who is specializing in the field of communications protocols security, gave a talk during this year’s Troopers IPv6 summit. He spoke about network reconnaissance techniques in IPv6 area and presented a brand new set of tools for this purpose.

Comparing with methods for IPv4, reconnaissance techniques for IPv6 should be different. It offers much larger address space, so such attacks as brute force address scanning are not feasible anymore, because it would take too much time to send one packet to each and every possible address. Fernando has also noted that in general network reconnaissance support in security tools has traditionally been poor. Together these facts prompt that it’s time for something new, and recently a new IETF RFC 7707 was published.

Tools for Troubleshooting and Monitoring IPv6 Networks

Sat, 02 Apr 2016 00:00:00 +0000

Yet another interesting 180-minute workshop in IPv6 Security Summit of TROOPERS16, which aimed to introduce the IPv6 troubleshooting and monitoring tools, which are essentially needed by users in order to know how to deal with IPv6 in any IPv6-enabled network.

Before we dive into this post, let me introduce you in few words “Gabriel Müller” the speaker and the instructor of this workshop. Gabriel works as a senior consultant at AWK Group by mainly assisting clients in the public and private sectors as a project manager and an expert in the network area.

Building a secure and reliable IPv6 Guest Wi-Fi Network by Christopher Werny

Fri, 01 Apr 2016 00:00:00 +0000

Christopher Werny leads the network security team for ERNW and since 2005 he is involved in numerous IPv6 projects where he is responsible for planning, implementation and troubleshooting existing projects.

The first topic he approached was “How to build a conference WLAN Network in General”. The very first suggestion was to put it to the 5GHz channel because there could be a lot of interferences in the 2.4 GHz channel. The basic idea here is to disable 802.11b completely if it´s possible in your environment and no-one is using it anyway. Further you should also consider nearby Wi-Fi signals and on which channels they reside. His next recommendation was about setting the inactivity timer to short intervals, this will avoid unnecessary resource spending from the APs when they try to track down moved or shut down devices. His last general recommendation from him was regarding a central DHCP Server. This will enable the roaming from mobile devices without getting a new IP-Address when bridged mode is enabled for the APs.

IPv6 Security Summit – Track 2

Tue, 29 Mar 2016 00:00:00 +0000

The Troopers experience will never be the same without the “IPv6 summit”. It is one of kind of two-day special event where different security experts gather to discuss IPv6 current challenges. It addresses different topics ranging from a broad introduction of the IPv6 to how secure the protocol is and what the latest standards are.

The summit is divided into 2 different tracks that run simultaneously. For the first day on the second track, Christopher Werny and Rafael Schaefer have carried out the first three sessions.

Troopers 16: Wireshark in IP version 6

Tue, 29 Mar 2016 00:00:00 +0000

Wireshark in IP version 6 workshop was a part of IPv6 summit sessions of Troopers 16. It was held by Jeffery Carrell on the second day of IPv6 summit on Tuesday, the 15th of March. The workshop was generally divided into two sections: a short introduction to IPv6 and analyzing some IPv6 packets on Wireshark.

Introduction to IPv6

IPv6 protocol was defined at the end of 1990’s, mainly to provide a huge address pool after realizing that the world would run out of IPv4 addresses quickly. The work on IPv6 started before the introduction of NAT and Private addressing to IPv4, which are considered temporary solutions of IPv4 address shortage problem. IPv6 address consists of 128 bits, divided into 8 groups called nibbles, quibbles or hextets separated by colons. Each nibble consists of four hexadecimal digits. The 128 bits address length provides 340 trillion trillion trillion addresses. An IPv6 address is divided into two parts: the left part is the network identifier while the right one is the host identifier. The default prefix is /64 which divided the IP address into two halves. An IPv6 address looks as follows: 2001:0db8:1010:61ab:f005:ba11:00da:11a5/64

Security Evaluation of Dual-Stack Systems [Troopers 2016 recap] (Part 1)

Mon, 28 Mar 2016 00:00:00 +0000

Dear Readers of Insinuator,

**tldr;**This blogpost presents a measurement study of a current security state regarding to open ports on a direct comparison of IPv4 and IPv6. The study analyses almost 58,000 dual-stacked domains in order to find discrepancies in applied security policies. We further discuss the potential reasons and, more importantly, the implications of the identified differences. \tldr;

For those of you who couldn’t participate at Troopers Conference 2016 in Heidelberg or watch my talk at the IPv6 Security Summit, I want to recap some of the most important parts of my research in this blogpost.

Reflections on the IPv6-only WiFi Experience during Troopers

Fri, 25 Mar 2016 00:00:00 +0000

Hello,

Troopers is (unfortunately) over. It was a blast (but I may be biased ;-))! After things have settled, I want to take the opportunity to reflect my thoughts and impressions on the IPv6-only WiFi we had deployed during the conference. To make sure that everybody is on the same page let’s start at the beginning.

In the last couple of years we had provided Dual-Stack connectivity on the main “Troopers” SSID but also had an additional IPv6-only SSID. This year we decided to spice things up and made the “Troopers“ SSID IPv6-only (with NAT64) while providing Dual-Stack connectivity on the “Legacy“ SSID. We wanted to get a feeling how many clients and applications can work properly in an IPv6-only environment. We intentionally didn’t announce it vastly beforehand, hoping that attendees would just connect to the main SSID without noticing anything. We were aware that some applications might expose issues but, as I said , we wanted to get a feeling to which degree problems actually occured.

Multicast Based IPv6 Neighbor Spoofing / Response Behavior on Cisco Devices

Tue, 01 Mar 2016 00:00:00 +0000

Dear readers,

today we want to examine the behavior of Cisco devices when they receive spoofed IPv6 Neighbor Advertisement packets from an untrusted system pretending to be the default router for the local segment. We start with a quick refresher how Cisco devices behave in the legacy (IPv4) world when they receive a spoofed broadcast ARP packet containing the IP address of the device but with a different MAC address, followed by a discussion of the corresponding behavior in the IPv6 world.

Dual Stack vs. IPv6-only in Enterprise Networks

Wed, 17 Feb 2016 00:00:00 +0000

I had the pleasure to sit in Mark Townsley “Addressing Networking Challenges With Latest Innovations in IPv6” session at Cisco Live yesterday and – somewhat inevitably – there was a mention of Facebook having implemented an IPv6-only approach in their data centers (here’s a talk from Paul Saab/FB laying out details). So, with the “IPv6 Panel” looming, I started reflecting on “Why don’t we see this in our customer space?”. This post quickly summarizes some observations and thoughts.

Observations from the Cisco Live Europe 2016 Wifi Infrastructure

Tue, 16 Feb 2016 00:00:00 +0000

Good Evening,

Enno and I spent the first day on Cisco Live Europe in Berlin today attending the “Advanced Practical Knowledge for Enterprise Deploying IPv6” technical breakout held by Tim Martin and Jim Bailey. It was a good breakout session, and thanks again Tim for the honorable mention of our work in your slides! We really appreciate it. Like last year, we were curious how the Wifi network was setup this year as I face a corresponding task for Troopers in March, with some major changes in comparison to the last years. The Wifi infastructure in Berlin looked very similar to the one from last year in Milan, we had the “standard” Cisco Live SSID as well as an IPv6-only (with NAT64 as translation mechanism) SSID. The standard SSID looked identical to last year with the exception that now the RA Throttling feature on the WLC was active from the beginning! Neither the M nor the O flag are set which means that my client has to use the legacy protocol to resolve AAAA records. As I am running Windows, it does not support RA option 25 but the option wasn’t included in the RAs anyway. The preference was configured to the default “medium”. One thing I noticed, but haven’t had a chance to ask Andrew Yourtchenko, was that for the legacy (IPv4) connection they use HSRPv2 as an FHRP protocol (indicated by the MAC address 00:00:0c:9f:f0:01 I received from the gateway) but for IPv6 I received Router Advertisements from two different MAC addresses (which both belong to Cisco, so I don’t think anyone sent spoofed RAs). I am curious about the reasoning for this approach 🙂
What i also encountered was that the Peer-to-Peer Blocking feature was apparently not enabled on the SSID as I was able to enumerate approx. 1600 active clients at the time. No worries, I haven’t done anything else, just was curious whether the feature was activated or not…

IPv6 Address Planning in 2016 / Observations

Sun, 14 Feb 2016 00:00:00 +0000

Hi,

I’ll be on the “IPv6 Panel” at Cisco Live next week and somewhat in preparation I started thinking about what we currently see when it comes to IPv6 deployment in our customer space. We notably observe a large gap between “textbook planning & transition strategies” and what’s happening in real-life in those organizations. I hence decided to write down some of these observations in a quick series of posts to be published in the upcoming days and, maybe more importantly, to reflect on the reasoning of this apparent mismatch between theory and practice. I dare to add a dose of devil’s advocate here+there…
For today let’s start with some comments on IPv6 address planning.

#TR16 IPv6 Security Summit Teaser: Basic IPv6 Attacks & Defenses Workshop

Sat, 13 Feb 2016 00:00:00 +0000

Dear Readers,

It’s me again with another teaser for an upcoming workshop at the IPv6 Security Summit. This one is a classic! If you happen to deploy IPv6 in your environment in the near future, but didn’t had the time to think about the security implications, this workshop is the right place to start.

We will start the workshop with a quick refresher of the core behavior of IPv6 to make sure that every attendee is on the same page. Before we start discussing and demonstrating various IPv6 attacks, we dive into (a little more abstract) topic of why IPv6 security actually isn’t that easy to implement. We will continue with IPv6 attacks targeted at the local link. Rafael and I will introduce commonly used IPv6 attack tools as well as performing various attacks in a dedicated lab environment. Every attendee is encouraged to participate in these exercises. We will provide you with the necessary tools; you just have to bring a laptop with (ideally) Linux installed. We will prepare some virtual machines including VMware Player in case your corporate laptop runs Windows.

Multiple Address Family OSPFv3

Wed, 10 Feb 2016 00:00:00 +0000

Dear Readers,

today I want to talk about OSPFv3. I won’t cover the glory details of OSPFv3, there are smarter guys than me out there who did that already 😉 and there are great resources to familiarize yourself with the protocol. However, it should be noted that OSPFv3 is not only OSPF for IPv6, OSPFv3 brought some major enhancements compared to OSPFv2. Wouldn’t it be cool to benefit from the enhancements in the IPv4 world as well?

#TR16 IPv6 Security Summit Teaser: First-Hop-Security on HP Network Devices

Tue, 09 Feb 2016 00:00:00 +0000

Hello Everybody,

Today I want to give you a little teaser about my upcoming talk at the IPv6 Security Summit about First-Hop-Security on HP devices. In the past I presented on about First-Hop-Security in the Cisco realm and in virtualized environments. Until recently, Cisco was mostly the only vendor who had a sufficient implementation of various IPv6 security features on their access-layer switches, but HP closed the gap considerably and it’s time to have an in-depth look at their implementation of those features.

#TR16 IPv6 Security Summit Teaser: Building a Reliable and Secure IPv6 WiFi Network

Mon, 08 Feb 2016 00:00:00 +0000

Hi everyone,

some of you may have seen my last blog post about the preparation of the Troopers network. Today I want to give you a little teaser on what to expect for the talk I will present during the IPv6 Security Summit. As the title implies, it’s not only about building a secure IPv6 WiFi, but also a reliable one. One might think that there aren’t many differences in comparison to IPv4, but the heavy reliance on multicast of IPv6 does have implications for Wi-Fi networks in general.

DHCPv6 Option 52 on Cisco DHCPv6 Server

Sat, 06 Feb 2016 00:00:00 +0000

Hi,

I am currently preparing the Troopers network in a lab environment to ensure that we all will have a smooth Wi-Fi experience during Troopers. I wanted to spice things up a little bit for the Wi-Fi deployment (more on that in a following blogpost) and get rid of IPv4 wherever possible. Our Wi-Fi infrastructure consists of typical Cisco Access Points (1602) and a 2504 Wireless LAN Controller. Beginning with WLC image 8.0 it is finally supported to establish the CAPWAP tunnel between the AP and the WLC over IPv6, which is awesome and I wanted to implement it right away.

Developing an Enterprise IPv6 Security Strategy / Part 6: Controls on the Host Level

Tue, 02 Feb 2016 00:00:00 +0000

In this part of the series (for the other parts see [1], [2], [3], [4], [5]) we’ll discuss approaches to implement security measures suited to protect from IPv6-related threats on the host level.

These can be grouped into the following generic categories each of which will be described in more detail in the following:

“Minimal machine” approach
Static configuration of IPv6 parameters
Tweaking the behavior of IPv6-related mechanisms/protocols
Local packet filtering

Some of you might recall that we published IPv6 hardening guides for both Linux and Windows a while ago and we’ll reference those exact documents below, by [Hard_Linux] and [Hard_Windows] respectively.

Things to Consider When Starting Your IPv6 Deployment

Mon, 11 Jan 2016 00:00:00 +0000

Hi,

today I’m going to suspend the “Developing an Enterprise IPv6 Security Strategy” series for a moment and discuss some other aspects of IPv6 deployment.
We’ve been involved in a number of IPv6 projects in large organizations in the past few years and in many of those there was a planning phase in which several documents were created (often these include a road map, an address concept/plan and a security concept).
Point is: at some point it’s getting real ;-), read: IPv6 is actually enabled on some systems. Pretty much all enterprise customers we know start(ed) their IPv6 deployment “at the perimeter”, enabling IPv6 (usually in dual-stack mode) on some systems/services facing the Internet and/or external parties.
Unfortunately there’s a number of (seemingly small) things that can go wrong in this phase and “little errors” made today are probably meant to stay for a long time (in German we have the nice phrase “Nichts ist so dauerhaft wie ein Provisorium”, and I’m sure people with an IT operations background will understand this even without a translator…).
In this post I will hence lay out some things to consider when you enable IPv6 on perimeter elements for the first time.

Developing an Enterprise IPv6 Security Strategy / Part 5: First Hop Security Features

Thu, 31 Dec 2015 00:00:00 +0000

In the previous parts of this series (part 1, part 2, part 3, part 4) we covered several aspects of IPv6 security, mainly on the infrastructure level. In today’s post I will follow up by briefly discussing so-called First Hop Security features.

IPv6 First Hop Security (“IPv6 FHS”) is a collection of features (initially implemented, and named, by Cisco but available on other platforms too) that can be found on many access layer switches to prevent different attacks in IPv6 networks. The availability of those features is sometimes divided into three phases and started in 2010 with the release of IOS images containing mainly RA Guard (see below) and port-based IPv6 ACLs. Phase two was released in early 2012 and contained some more features (namely from the “IPv6 Snooping” framework) whereas phase three was released at the end of 2012 and contained some more advanced features (e.g. IPv6 Source Guard). Nowadays usually “phase one” features are supported on many platforms, at least on physical ones (support on virtual switches is still somewhat lacking).
There’s an excellent Cisco FHS Wiki maintained by Andrew Yourtchenko, Scott Hogg wrote a good overview, as did Ivan Pepelnjak, and this is a nice presentation on some elements by Jim Small from 2013. Still, from our perspective the main question is: which of those features should be deployed in production networks/can be observed in real-life enterprise networks. Actually it’s only two:

#TR16 IPv6 Security Summit – New Talks Added

Wed, 23 Dec 2015 00:00:00 +0000

In the interim we’ve worked on the agenda of next year’s IPv6 Security Summit (for those not familiar with the event, here’s the 2015 edition and here the one of 2014), and some new talks have been added.

Rafael Schaefer: Advanced IPv6 Attacks Using Chiron. Hands-On Workshop

Outline: During the IPv6 Security Summit at Troopers 14, Chiron, an all-in-one IPv6 penetration testing framework was released publicly for first time. Since then, the advanced features of Chiron were used to discover some 0-day evasion techniques against high-end commercial and open-source Intrusion Detection / Prevention Systems. Moreover, for Troopers 15 it was enhanced with new features, like advanced MLD support and a fake DHCPv6 server, which can be combined with its other features, like the use of arbitrary Extension Headers and fragmentation to leverage really advanced attacks.
In this workshop, after a quick refreshing to the basic capabilities of Chiron, we will focus on the advanced IPv6 functionalities that the framework offers. We will not only show how to reproduce the latest published IPv6 attacks, but moreover, how you can create your own arbitrary IPv6 attacking scenarios for your own security assessments or penetration testing purposes. A lab will be set up in order not only to reproduce the presented techniques, but to also try your skills and – why not – to discover your own 0-day techniques :).

Developing an Enterprise IPv6 Security Strategy / Part 4: Traffic Filtering in IPv6 Networks (II)

Tue, 22 Dec 2015 00:00:00 +0000

In this part of our little series (part 1, part 2, part 3) we continue discussing IPv6 specific filtering of network traffic, namely at intersection points.

As stated in the 1st part, a number of potential security problems in IPv6 networks are related to Extension Headers of IPv6, in particular when combined with fragmentation. At the same time, as of today (December 2015) there is no Internet service or application that actually needs those headers.

Developing an Enterprise IPv6 Security Strategy / Part 3: Traffic Filtering in IPv6 Networks (I)

Mon, 14 Dec 2015 00:00:00 +0000

So this is the third part of our little series on securing IPv6 in enterprise environments. In the first part we tried to develop an understanding of threats in IPv4 networks as a kind-of baseline while analyzing the main differences induced by IPv6 and in the second part we laid out protection strategies on the infrastructure level, focusing on network isolation on the routing layer. Today I’ll dive into discussing IPv6-specific filtering of network traffic.

Developing an Enterprise IPv6 Security Strategy / Part 2: Network Isolation on the Routing Layer

Mon, 07 Dec 2015 00:00:00 +0000

In the first part of this series we tried to identify which risks related to network-related threats actually change when IPv6 gets deployed and hence which ones to take care of in a prioritized manner (as opposed to those which one might be tempted to [initially] disregard with a “has been there in IPv4 already and we did not address it then, why now?” stance). Let’s assume we went through this step and, for those most relevant risks we identified, we want to come up with infrastructure level controls first, before tackling controls to be deployed on the host level (as in many organizations the sysowners of “hosts” like servers in datacenters tend to expect “the network/infrastructure guys to provide the 1st layer of defense against threats”, in particular once those originate from an apparent network layer protocol, that is IPv6).

Developing an Enterprise IPv6 Security Strategy / Part 1: Baseline Analysis of IPv4 Network Security

Wed, 02 Dec 2015 00:00:00 +0000

We’ve been involved in some activities in this space recently and I thought it could be a good idea to share a couple of things we’ve discussed & displayed. Furthermore some time ago – in the Is IPv6 more Secure than IPv4? Or Less? post – I announced to come up with (something like) an “IPv6 threats & controls catalogue” at some point… so here we go: in an upcoming series of a few blogposts I will lay out some typical elements of an “Enterprise IPv6 Security Strategy” incl. several technical pieces (and I plan to give a talk on the exact topic at next year’s IPv6 Security Summit).

Some Notes on the “Drop IPv6 Fragments” vs. “This Will Break DNS[SEC]” Debate

Tue, 03 Nov 2015 00:00:00 +0000

Some readers will probably be aware that we are amongst the proponents of a quite strict stance when it comes to filtering IPv6 packets with (certain) Extension Headers and/or fragmentation, because those can be the source of many security problems (as laid out here, here or here). Actually I still think it was a very good idea of, amongst others, Randy Bush and Ron Bonica to suggest the deprecation of IPv6 fragmentation in the IETF.
On the other hand there are voices arguing that fragmented IPv6 packets will be needed in some cases, namely DNS[SEC]-related ones.
In this post I will discuss some details of this debate (taking place in many circles, incl. this thread on the ipv6-hackers mailing list which, btw, you should subscribe to).

The Strange Case of $SOME_SOFTWARE Adding an IPv6 Extension Header, and an Internet Router Dropping Them

Mon, 05 Oct 2015 00:00:00 +0000

Last week Christopher and I were the instructors of an IPv6 workshop. In this one we usually build a lab with the participants incl. a variety of routed segments and native IPv6 Internet access. Once the latter part is implemented people start poking around and surfing the Internet from their laptops, not least to find out which sites they can actually reach from an v6-only network (please note that actually there are many).

IPv6@MRMCD2015

Mon, 14 Sep 2015 00:00:00 +0000

Greetings everyone,

On Saturday last week I had the pleasure of delivering a workshop on IPv6 networking at the MRMCD2015 conference in Darmstadt, Germany. It goes without saying that the atmosphere was quite amicable; as usual at CCC-related events. What definitely impressed me the most was the diversity of the audience. There were around thirty attendees representing several age groups and all with seemingly differing backgrounds.

The engagement of everyone was stunning. I questioned the most engaged attendees relentlessly and they fired back. I was being constantly bombarded with questions from enthusiastic geeks and they got, hopefully, what they deserved. This provided for a great learning environment, a friendly atmosphere and in my humble opinion really constructive dialogues. Well, one has to be interested and enthusiastic in order to spend three hours on a rainy Saturday evening discussing IPv6.

IPv6 Hackers Meeting @ IETF 93 in Prague

Wed, 29 Jul 2015 00:00:00 +0000

After the first “IPv6 Hackers Meeting” held two years ago in Berlin, Fernando Gont kindly organized a similar event in Prague last week.

Although a bit on short notice it was a good meeting with interesting discussions. I contributed with shortened versions of two talks we had delivered in the past:

the “Evasion of High-End IDPS Devices at the IPv6 Era” talk which Antonios, Rafael and I had given at Black Hat US & Europe 2014. The accompanying white paper with the exact details can be found here; the tool Chiron here (and a tutorial here).
the “MLD Considered Harmful” talk that Antonios, Jayson and I had presented at the Troopers IPv6 Security Summit 2015. The mentioned Internet-Draft on MLD security which Eric Vyncke, Antonios and myself are working on can be found here. We’re happy to receive any feedback on that one.

Special thanks go to Jan Zorz and to CZ.NIC for hosting us and providing refreshments. Much appreciated, guys!

Evasion of Cisco ACLs by (Ab)Using IPv6 – Part 2

Wed, 08 Jul 2015 00:00:00 +0000

When we wrote our initial blogpost regarding the evasion of Cisco ACLs by (Ab)Using IPv6, where we described (known to Cisco) cases of Access Control Lists (ACL) circumvention, we also suggested some mitigation techniques including the blocking of some (if not all) IPv6 Extension Headers.
Almost a month later, we got a comment from Matej Gregr that, even if the ACLs of certain Cisco Switches are configured to block IPv6 Extension headers like Hop-by-Hop or Destination Options headers, this does not actually happen/work as expected. Of course this made us re-visit the lab in the interim ;-).

NANOG64

Fri, 26 Jun 2015 00:00:00 +0000

I recently had the pleasure to join the 64th NANOG (North American Network Operators’ Group) meeting in San Francisco, which can be understood as one of the largest Internet engineering conferences at all. It takes place three times a year at different locations in North America.

What I personally like about NANOG is its strong collaborative and cooperative character. It is not about single persons and also not too much about spectacular projects but more about discussing technologies, ideas, challenges and numbers. Every talk has a comparatively large time slot reserved for discussion, which is often more than fully used. Discussion is typically actively focused and is more time-consuming (and even more relevant) than the talk itself. Which often is intended by the community. The climate of discussion is almost always impressively polite and constructive, even for controversially discussed topics.

IPv6 Adress Planning / Some Notes

Tue, 16 Jun 2015 00:00:00 +0000

In the course of a customer project I recently documented some thoughts and general objectives of IPv6 address planning, expanding on stuff I wrote a while ago in the series on “Address Plan Considerations”. An excerpt of that (newer) document can be found here. Due to the context it originates from it’s in German, still I hope it’s useful for some readers.
If you’re interested in the topic it might be a good idea to listen to Tom Coffeen‘s talk at the upcoming IPv6 Business Conference, too.

Is IPv6 more Secure than IPv4? Or Less?

Mon, 08 Jun 2015 00:00:00 +0000

Scott Hogg recently (in his post “Holding IPv6 Neighbor Discovery to a Higher Standard of Security“) gave the following answer:

“The security of IPv4 is roughly equivalent to IPv6. So why do we expect more from IPv6?”

While I highly value Scott’s IPv6 expertise – not least because I learned a lot about IPv6 security from the book on the topic he wrote together with Eric Vyncke – I strongly disagree with his statement, mainly with the first part. In this post I will lay out why I think that IPv6 is actually less secure than IPv4.

IPv6 & Complexity

Wed, 27 May 2015 00:00:00 +0000

IPv6 is often called a “complex protocol”, not least by myself (for example in my keynote to the IPv6 Security Summit 2014). In this post I want to have a quick look at three questions:

– Can IPv6 be considered a “complex protocol”?
– Is it “more complex” than IPv4?
– Can we expect IPv6 networks to be “complex networks”?

I’d like to start with some clarifications and a definition. First of all: when I discuss IPv6 “as a protocol”, this actually means “the IPv6 procotol family” incl. those helper protocols needed to support (“core”) IPv6 in performing properly in most networks, like ICMPv6 and MLD.
Then, of course, we have to define the term “complexity”, which is a difficult task in itself. [MITCHELL2009] gives an overview of several potential (definition) approaches in a dedicated chapter and the same undertaking is performed – in quite different ways – by most of the authors of individual contributions to [PELITI1988].

RIPE70 in Amsterdam

Sun, 24 May 2015 00:00:00 +0000

Two weeks ago Christopher and I joined the RIPE70 meeting in Amsterdam. Being part of the group was fun as always and we had quite some interesting conversations with peers from the IPv6 community.

We could even contribute a bit to some discussions, with two talks. I gave one titled “Will It Be Routed? – On IPv6 Address Space Allocation & Assignment Approaches in Very Large Organizations” in the Address Policy Working Group session on Wednesday. This is the abstract:

OS IPv6 Behavior in Conflicting Environments

Thu, 30 Apr 2015 00:00:00 +0000

I was invited by the Swiss IPv6 Council to give a talk on this topic yesterday. We had good conversations after the talk – thanks for the invitation!

For those interested the slides can be found here. I will happily discuss the intricacies of DHCPv6 and how to deploy it in complex environments at the upcoming IPv6 Business Conference in Zurich and in my “IPv6 in Enterprise Networks” training in Berlin.

Have a great day everybody

SI6 Networks’ IPv6 Toolkit v2.0 (Guille) released at the Troopers IPv6 Security Summit

Sun, 05 Apr 2015 00:00:00 +0000

This is a guest post from Fernando Gont.

On March 16^(th), 2015, at the Troopers IPv6 Security Summit, we finally released the SI6 Networks’ IPv6 Toolkit v2.0 (Guille). The aforementioned release is now available at the SI6 IPv6 Toolkit homepage. It is the result of over a year of work, and includes improvements in the following areas:

Increased portability
Bug fixes
Additional features in existing tools
Brand-new tools

Increased Portability

One of the goals that the SI6 Toolkit had since its inception is that of portability. The SI6 Toolkit has supported all major BSD-derived OSes, Linux, and Mac OS for a number of years now. And this new release supports yet another new platform: OpenSolaris. We believe that besides supporting a greater user base, increased portability ultimately results in improved code quality.

MLD, a tale on Complexity in IPv6

Sat, 04 Apr 2015 00:00:00 +0000

The purpose of this blog post is to elucidate how and why MLD, an IPv6 protocol we’ve been lately talking quite a bit about, is an unnecessarily complex beast . This article should also serve to summarize a couple of points we’ve mentioned during our talks about MLD but which because of time constraints never make it into the main discussion. We’ve talked about other aspects of MLD in previous posts. So, have a look at those if this is a topic which you find interesting. Without further ado, let’s start for today.

IPv6 Router Advertisement Flags, RDNSS and DHCPv6 Conflicting Configurations

Mon, 09 Mar 2015 00:00:00 +0000

We’ve just released a whitepaper discussing the behavior of different operating systems once they receive IPv6 configuration parameters from different sources. For that purpose a number of lab tests were conducted.

In short, it’s a mess. Again, RFC ambiguity and/or (perceived) vendor implementation freedom suck big time. For us practitioners out (t)here this means (once more) we need extensive test labs and good troubleshooting guides for large scale IPv6 deployments.

The detailed results can be found in this paper. We hope to contribute to a better understanding of IPv6 specifics. I mean, after all it’s here already.

Practical IPv6 Troubleshooting while Setting up the Troopers Network

Mon, 09 Mar 2015 00:00:00 +0000

Hello Everyone,

Troopers is right around the corner and as I am responsible for the whole conference network I wanted to make sure that everything is working as expected. I went to the venue on Friday because of two things I wanted/needed to setup. Compared to last year’s setup we had a couple of changes in regards to the provider connection (resulting in some changes for our network setup). First, we now have a rather big pipe for the uplink and more importantly (well that depends on the point of view ;)) there is a native IPv6 connection. Before that I had to tunnel all IPv6 traffic from the venue to one of our gateways and to forward it out (as native IPv6) from there. As this step isn’t necessary anymore, and the staff on the venue isn’t that experienced with IPv6, I had in mind to setup and verify that IPv6 is working as desired. The router used over there is a Mikrotek Routerboard. As I haven’t worked with these devices before, I was curious whether everything works as it should ;).

An MLD Testing Methodology

Fri, 06 Mar 2015 00:00:00 +0000

Based on recent research in the ERNW IPv6 lab and with our MLD talk looming we’ve put together a (as we think) comprehensive document discussing how to thoroughly test MLD implementations in various components (network devices or servers/clients). We hope it can contribute to a better understanding of the protocol and that it can serve as either a checklist for your own environment or as a source of inspiration for researchers looking at MLD themselves.

A Chiron Workshop at the IPv6 Security Summit of Troopers 15

Wed, 04 Mar 2015 00:00:00 +0000

This is a guest post from Antonios Atlasis.

Last year, during the IPv6 Security Summit of Troopers 14 I had the pleasure to present publicly, for first time, my IPv6 Penetration Testing / Security Assessment framework called Chiron, while later, it was also presented at Brucon 14 as part of the 5×5 project. This year, I am returning back to the place where it all started, to the beautiful city of Heidelberg to give another workshop about Chiron at the IPv6 Security Summit of Troopers 15. But, is it just another workshop with the known Chiron features or has something changed?
I would say a lot :). The most significant enhancements are described below.

What to Do Today if You Want to Deploy IPv6 Tomorrow

Tue, 03 Mar 2015 00:00:00 +0000

Today I gave a talk with said title in a private setting. Assuming the content might be of interest for some of you, we published the slides here.

As always we’re happy to receive comments or feedback.
Cheers

Enno

IPv6-related Requirements for Security Devices

Sun, 08 Feb 2015 00:00:00 +0000

This is the sequel to the similar post on “IPv6-related Requirements for the Internet Uplink or MPLS Networks“. As mentioned there these requirements were created in the course of an RfP for network security services. The goal of this document was to provide a check list of IPv6-related requirements that security devices being part of the individual providers’ offerings have to fulfill in order to fully support the future IPv6 network.

IPv6 Hardening Guide for OS X

Wed, 04 Feb 2015 00:00:00 +0000

Similar to the documents we released for Linux and Windows (and actually inspired by a comment to the post on the Linux guide) Antonios wrote another guide, this time for Mac OS X.

It can be found here. We hope some of you might find it helpful.
Have a great day

Enno

PS: in the past we also made a general Mac OS X hardening document available and we’ve discussed an additional patch in this post.

Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6

Wed, 04 Feb 2015 00:00:00 +0000

One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6 in some other posts – many practitioners have been waiting for quite some time now, is full support of RFC 6939 (Client Link-Layer Address Option in DHCPv6) by network devices (acting as relays) and DHCPv6 servers. RFC 6939 support would allow a number of things which large organizations use in their DHCPv4 based networks, incl.

reservations (assigning a kind-of fixed DHCP address based on the MAC address of a system which in turn allows for “centralized administration of somewhat static addresses”).
correlation of IPv4 and IPv6 addresses of a given host identified by its MAC address.
(some type) of security enforcement based on the MAC address of a host gathered in the course of a DHCP exchange (see for example slide #29 of this presentation of the IPv6 deployment at CERN, btw: slide #9 might be helpful when discussing IPv6 transition plans with your CIO. or not).

So far it seemed very few components support RFC 6939. When Tim Martin mentioned at Cisco Live that Cisco devices running IOS XE support it by default, we decided go to the lab ;-).

IPv6-related Requirements for the Internet Uplink or MPLS Networks

Sat, 31 Jan 2015 00:00:00 +0000

We’re currently involved in a complex RfP procedure for global network services of a large organization. As part of that we were asked to define a list of IPv6 related requirements as for the Internet uplink and MPLS circuit connections. The involved service providers/carrier offerings will be checked to comply with those.

As a source of inspiration we mainly used the excellent “What To Ask From Your Service Provider About IPv6” document from Cisco, and enhanced that with stuff we observed in other environments (go wrong), namely with regard to MTU/PMTUD and in the space of prefix filtering. Here’s the first draft list we came up with:

Evaluation of IPv6 Capabilities of Commercial IPAM Solutions

Wed, 28 Jan 2015 00:00:00 +0000

Originating from a customer IPv6 deployment project, in early 2014 we defined a number of requirements as for the IPv6 capabilities of IPAM solutions, with a certain focus on security-related requirements (due to the specific environment of the project). We subsequently performed a practical evaluation of several commercial solutions, based on documentation, lab implementation and vendor communication.

We just released a newsletter describing the requirements and the results of the evaluation.
It should be noted that in the interim newer versions of the evaluated products might be available which might have enhanced features. Hence, from our perspective, understanding the requirements of an individual environment might even be more important than the actual results described in that document (as those only reflect a certain point of time). We hope to contribute here to a well-informed requirements definition and decision taking process on your side.
Feel free to get back to us on any of the points laid out or, even better, join us at the Troopers IPv6 Security Summit in Heidelberg on Mar 16th/17th in order to discuss any related points.

Evasion of Cisco ACLs by (Ab)Using IPv6 & Discussion of Mitigation Techniques

Wed, 28 Jan 2015 00:00:00 +0000

This is a guest post of Antonios Atlasis.

During our blogpost regarding DHCPv6 Guard evasion, one of the side-effects was that Access Control Lists (ACLs) configured to block access to UDP ports 546 can be evaded by abusing (again) IPv6 Extension headers. Having that in mind, we decided to check the effectiveness of Cisco IPv6 ACLs under various scenarios. Our goal was to examine whether the IPv6 ACLs of Cisco routers can be evaded, as well as under which conditions this can take place. To this end, several representative scenarios from enterprise environments or other potential ones are examined.

The Persistent Problem of State in IPv6 (Security)

Wed, 28 Jan 2015 00:00:00 +0000

I’ve discussed the heavy complexity of IPv6 and its negative impact on security architectures relying on state – you know, “stateful” firewalls and the like 😉 – before (here and here. btw, the widely discussed IPv6-related network outage at MIT last year was a state problem as well: switches keeping track of multicast groups, of which in turn many existed due privacy extensions combined with the unfortunate relationship of MLD and ND).

One of the conclusions I’ve drawn in the past was recommending to minimize the amount of state one might use within security architectures in the IPv6 world. First, this is bad news for quite some well-established security controls that need a certain amount of state to work properly, like IDPS systems – which subsequently have hard times to work properly in IPv6 networks.
Secondly there’s another severe caveat. As I fully realized yesterday, at Cisco Live Europe, in Andrew Yourtchenko‘s excellent breakout session on “Advanced IPv6 Security in the Core”, this carries some consequences for stateless (and hence: seemingly “unaffected”) security controls, too.

Observations from the Cisco Live Europe Wifi Infrastructure

Tue, 27 Jan 2015 00:00:00 +0000

Given that Enno and I are network geeks, and that I am responsible for setting up the Troopers Wifi network I was curious which components might be used at Cisco Live and which IPv6 related configuration was done for the Wifi network to ensure a reliable network and reduce the chatty nature of IPv6. Andrew Yourtchenko (@ayourtch) already did an amazing job last year at Cisco Live Europe explaining in detail (at the time session BRKEWN-2666) the intricacies of IPv6 in Wifi networks, and how to optimize IPv6 for these networks. He was also a great inspiration for me when setting up the Troopers Wifi network a couple of weeks later. Thank You!

Troopers15 IPv6 Security Summit

Tue, 20 Jan 2015 00:00:00 +0000

We’ve finalized the agenda for this year’s IPv6 Security Summit. Here’s an overview of the event:

The “IPv6 Security Summit” is a special two-day convention in the context of the Troopers security conference. It will be run in two tracks of both half-day workshops and 90 minute presentations on specific topics. The goal is to foster the discussion of IPv6 security aspects & issues and to provide practical advice for security officers, network planners and practitioners in the IPv6 security field.

Main IPv6 Related Mailing Lists

Sat, 17 Jan 2015 00:00:00 +0000

We’re sometimes approached with the question “Which IPv6 mailing lists do you guys read/subscribe to?” – here’s a quick overview of the main ones guys like Christopher, Patrick, Rafael, Antonios and myself are periodically lurking at, to discuss IPv6 (network|security) related stuff with other practitioners and to learn from them:

ipv6-ops.
This list is a forum for people who are actually deploying IPv6 in the Internet. Its focus is on OPERATIONAL issues.
http://lists.cluenet.de/mailman/listinfo/ipv6-ops/

How To Configure Snort to Stop IPv6 Evasion Attacks

Sun, 11 Jan 2015 00:00:00 +0000

This is a guest post from Antonios Atlasis.

Hi all,

during our BlackHat US 2014 talk titled “Evasion of High-End IPS Devices in the Age of IPv6”, among others we discussed a Snort preprocessor rule (116:456) which, when enabled (not the case by default), triggers an alert when an IPv6 datagram with nine (9) or more IPv6 Extension Headers is used (such a header was used by us to evade Snort). However, we mentioned that:

DHCPv6 Guard: Do It Like RA Guard Evasion

Thu, 08 Jan 2015 00:00:00 +0000

Or: When Cisco ACL Can Count Up to Five 🙂

This is a guest post by Antonios Atlasis.

Hi all,

RA Guard Evasion is well-known in the IPv6 “circles”; there is RFC 7113 Advice for IPv6 Router Advertisement Guard (RA-Guard) and many interesting blog-posts like this one here, here, and this excellent write-up here that discuss this issue.
Moreover, as Jim Smalls states in his comprehensive “IPv6 Attacks and Countermeasures” presentation given at the North American IPv6 Summit 2013, DHCPv6 Guard or a corresponding IPv6 ACL can stop a DHCPv6 Rogue Servers, but (only?) for non-malicious/non-fragmented DHCPv6 packets (slide 35). However, at that time there wasn’t any known attack tool in the wild that had the fragmentation evasion built in.

Should IPv6 Packets With Source Address ::1 Be Processed When Received on an External Interface?

Mon, 05 Jan 2015 00:00:00 +0000

This is a guest post from Antonis Atlasis.

Most of you are probably aware of the recently discovered/-closed severe ntpd vulnerabilities (CVE-2014-9293, CVE-2014-9294, CVE-2014-9295, CVE-2014-9296, see also the initial ntp.org security notice). Some days ago the Project Zero team at Google published a blog post “Finding and exploiting ntpd vulnerabilities” with additional details. In this one they mentioned a seemingly minor but quite important detail: on a default OS X installation one of the built-in protection mechanisms of ntpd (that is the restriction to process certain packets only if they are sourced on the local machine) can easily be circumvented by sending IPv6 packets with a spoofed source address of ::1 (the equivalent to 127.0.0.1 in IPv4 which would be discarded by the kernel once received from an external source).

IPv6 Hardening Guide for Windows Servers

Mon, 22 Dec 2014 00:00:00 +0000

After we recently released the “Linux IPv6 Hardening Guide” we got a number of suggestions “could you pls provide a similar document for $OS?” (btw: thanks to you all for the overwhelming interest in the Linux document and the active discussion of ip6tables rule approaches on the ipv6hackers mailing list).

Hence Antonios thankfully decided to put together a list of configuration steps for Windows servers. It can be found here.

Once more we’d like to emphasize that the approach described is only suited for very specific environments with high security requirements and an associated ratio of “generous operational resources”. From our perspective this guide is intended mostly to serve as a source of inspiration (“what could be done”) and for documentation purposes (“how to do it”). Everything described should be carefully tested in your specific environment.
For example, we were recently involved in IPv6 security planning in an organization where the Windows guys (completely legitimately) came up with a stance of “before we fully accept and ratify the strategy and policy just discussed, we’d like to get feedback from Microsoft, if we still have full support once we follow this path”.

IPv6 Hardening Guide for Linux Servers

Wed, 17 Dec 2014 00:00:00 +0000

We were recently approached by a customer asking us for support along the lines of “do you have any recommendations as for strict hardening of IPv6 parameters on Linux systems?”. It turned out that the systems in question process quite sensitive data and are located in certain, not too big network segments with very high security requirements.

They indicated they were willing to spend significant operational resources on “securely configuring them”. So Antonios deciced to write a small hardening guide for IPv6 on Linux, mostly focusing on manual configuration of pretty much everything (including neighbor cache entries 😉 with accompanying deactivation of all automatic mechanisms, together with ip6tables based local packet filtering.
The document can be found here.

Penetration Testing Tools that (do not) Support IPv6

Thu, 11 Dec 2014 00:00:00 +0000

We just released a white paper authored by Antonios Atlasis that provides an overview which pentesting tools currently support IPv6 and how to (still) use them if that’s not the case. It can be found in our newsletter section.

Best

Enno

Security Implications of Using IPv6 GUAs Only

Mon, 01 Dec 2014 00:00:00 +0000

When planning for IPv6 addressing, many organizations – rightfully & wisely – decide to go with global unicast addresses (GUAs) only (hence not to use unique local addresses/ULAs as of RFC 4193 at all), in order to avoid address selection hell or just for simplicity & consistency reasons. This post discusses security implications and complementary security controls of such an approach.

In their IPv4 networks, most of these organizations currently use RFC 1918 space, combined with NAT for specific connections or use cases. Ideally NAT is only in place “where strictly needed”, in practice it’s often used as a kludge to conceal of all types of bad network design or debatable application architectures. I won’t enter the “is NAT a security control?” debate here, one statement might be allowed though: as of section 3 (“Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links.”) RFC 1918 space is usually not reachable from the Internet. So using such address space for internal networks is a nice example of the isolation principle as of the “Seven Sisters” approach we like to use. Now, bringing NAT into these networks enables connections (usually between trusted and untrusted networks) which simply would not be possible without it [NAT], so this actually breaks the isolation property. Question: how can one ever call something that increases the number of possible interactions between assets and potential attack originators a ‘security control’?!

IPv6 in RFIs/Tendering Processes

Fri, 28 Nov 2014 00:00:00 +0000

In one of our customer environments each vendor offering an IT product/solution is asked to fill out a questionnaire collecting information on a number of technical parameters with regard to their product[s]. We were recently asked to come up with a proposal of 8 to 10 IPv6-related questions to be added to the questionnaire/process. Here’s what we suggested:

When displaying, storing or exporting IP addresses, can your solution correctly handle IPv6 addresses of all types (link-local, ULAs, GUAs)?
When receiving IP addresses as input or processing them (e.g. in a database), can your solution correctly handle IPv6 addresses of all types (link-local, ULAs, GUAs) and of variable length?
Does your solution implement RFC 5952 in the sense that input (of IPv6 addresses) can be in any format, but output (e.g. in log files) follows the RFC 5952 recommendation?
Can your solution handle both A and AAAA records from DNS?
Does your solution use link-local or GUAs/ULAs for intra-subnet communication? Which is the default and can both types of addresses be configured?
Does your product/offering comply with any of the profiles in the ripe-554 requirements specification?
[http://www.ripe.net/ripe/docs/ripe-554]
Do all security-related functions of your solution (e.g. traffic filtering/ACLs, blacklisting, logging) fully support IPv6, with performance being equal to that of IPv4?
Do all implementations of management interfaces & protocols (SNMP, syslog etc.) used within your solution fully support IPv6?
Does your solution have a built-in webserver? Can this be configured to listen on an IPv6 address and has it been tested to successfully work in an IPv6-only or dual-stack setting?
Has your solution been thoroughly tested in an IPv6 only or in a dual-stack setting? Please provide proper test documentation.
In dual-stack settings which approach (e.g. Happy Eyeballs as of RFC 6555) does your solution follow as for preferring IPv6 over IPv4 or vice versa? Can this be configured/adjusted if needed?

MLD Considered Harmful?

Thu, 27 Nov 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis.

On Thursday the 20^(th) Enno, Jayson and I had the pleasure to present our latest research results regarding MLD at Deepsec 2014, both from vendors’ implementation perspective as well as regarding protocol design flaws (some preliminary results as well as our testing methodology were discussed here and here).

For refreshing out memory, in a nutshell, the purpose of MLD, a subprotocol of IPv6, is to inform routers about the presence of nodes which are interested in receiving specific multicast traffic (RFC 2710). The newer version of MLD, MLDv2 adds the ability for source address selection (RFC 3810).

MLD to Be Reconsidered?

Fri, 14 Nov 2014 00:00:00 +0000

This is guest post from Antonios Atlasis.

Following my September post about the connection between MLD and Neighbor Discovery, as well as Enno’s introduction about our upcoming talk at DeepSec, I would like to try to enlighten you about this with some technical details. First, we have some facts:

MLD is pre-enabled in most modern Operating Systems.
MLD traffic is sent out-of the-box during the stack initialization, as well as periodically.
They also interact with/respond to MLD Queries without any further configuration.

To run the tests, first we wrote down all potential security issues that may arise by (ab)using MLD, starting from the simple ones, like:

Protocol Properties & Attack Vectors

Thu, 13 Nov 2014 00:00:00 +0000

Next week, at DeepSec, we’re going to give a talk about Multicast Listener Discovery (MLD), a component of IPv6 which is realized by means of ICMPv6 messages. There are two versions of MLD (mainly specified in RFC 2710 and RFC 3810 respectively) and while MLD is technically implemented by ICMPv6 exchanges, these specifications describe a whole set of rules and communication formats, hence we can safely talk about “the MLD protocol”.

Now, you might ask: how does one tackle the task of examining the security “of a protocol”?

Dynamics of IPv6 Prefixes within the LIR Scope in the RIPE NCC Region

Thu, 06 Nov 2014 00:00:00 +0000

To contribute to the current debate on IPv6 route deaggregation & “strict-filtering” performed by certain ISPs we just released a white paper on “Dynamics of IPv6 Prefixes within the LIR Scope in the RIPE NCC Region“. I will give a talk on the overall topic later today at the Routing Working Group. We sincerely hope that the IPv6 community becomes aware of the inherent issues, and that practical solutions can be found which consider & meet the needs of the different parties involved.

IPv6 for IPv4 Experts

Tue, 04 Nov 2014 00:00:00 +0000

If any of you is interested in the intricacies of IPv6 Neighbor Discovery (ND) I briefly referred to in the course of my series on DHCPv6, I recommend reading section 5.2 “The Host, the Link, and the Subnet in IPv6” of Yar Tikhiy’s excellent ebook “IPv6 for IPv4 Experts”. It can be found here.

Best

Enno

I Don’t Have Any Neighbors – A Deep Dive into DHCPv6, Part 1

Fri, 31 Oct 2014 00:00:00 +0000

Probably due to the (“secondary”) role it has been historically assigned within the IPv6 universe, DHCPv6 is a protocol which is very different from its IPv4 counterpart. Some of the differences and similarities have been discussed recently (e.g. see Scott Hogg‘s article on “High Availability DHCPv6“). This post aims at covering a fundamental, yet widely unknown or misunderstood difference, that is the properties of DHCPv6 addresses and their behavior on the local-link.

Router Advertisement Options to the Rescue – A Deep Dive into DHCPv6, Part 2

Fri, 31 Oct 2014 00:00:00 +0000

This is the sequel post to the first part in which I mainly covered some elements of the specification wrt the “on-link” flag and the IPv6 subnet model.
In short each IPv6 address has an associated flag which determines if the host considers the respective address to be part of “a network where neighbors exist”. If this is the case ND is performed to talk to them, otherwise all communication with other hosts on that prefix is sent to the router. This flag is NOT set for DHCPv6 addresses (and, btw, just to make this clear already, there’s no way of setting it as part of the DHCP configuration procedure either) so communication with hosts with the same DHCPv6 provided prefix is supposed to go through a router, which in turn is very different (behavior) from the IPv4 world.

A “Please, Don’t Waste my Time” Approach and the Sourcefire/Snort Evasion

Sat, 18 Oct 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis.

Yesterday we (Rafael Schaefer, Enno and me) had the pleasure to deliver together our talk at BlackHat Europe 2014 named Evasion of High-End IDPS Devices at the IPv6 Era (by the way, latest slides can be found here and the white paper here). In this talk we summarised all the IDPS evasion techniques that we have found so far. At previous blogposts I had the chance to describe how to evade Suricata and TippingPoint. In this post I am going to describe some other techniques that can be used to evade Snort, and its companion commercial version, Sourcefire. The tool used to evade these IDPS is – what else – Chiron.

Deaggregation by large organizations

Wed, 15 Oct 2014 00:00:00 +0000

Some hours ago Iljitsch van Beijnum posted an email with the above subject to the RIPE Best Current Operational Practices (BCOP) mailing list.
Therein he describes the growing issue of (IPv6 prefix) deaggregation desires/approaches by certain organizations vs. the filtering practices of other organizations (providers). I touched this problem, from an enterprise’s perspective, some time ago in the second part of my blog post series on IPv6 address planning. Given we think that the discussion is heavily needed from several angles, I had actually submitted a talk on the topic twice (for the RIPE meeting in Warsaw in May and the upcoming one in London) which was unfortunately rejected at both occasions.
I’m hence very happy to see that a dialogue about the inherent dilemma might be started by Iljitsch’s mail. As a contribution to the development of a BCOP document I will hereby publish our draft slides of the talk which was initially planned. Furthermore two fellow IPv6 practitioners (Hi Roland & Nico!) and I plan to release a detailed paper with research results as for IPv6 prefix distribution at major European IXs in the near future.

North American IPv6 Summit 2014

Tue, 14 Oct 2014 00:00:00 +0000

Hello everyone,

I know I am a bit late with this post, but I was speaking on the North American IPv6 Summit in Denver three weeks ago. The focus of my talk was on Why IPv6 Security is hard – Structural Deficits of IPv6 & Their Implications (slightly modified/updated from the Troopers IPv6 Security Summit). We consider the NA IPv6 Summit as one of the most important IPv6 events at all and we were happy to contribute to the overall success. The conference was organized for the 7^(th) time by the Rocky Mountain IPv6 Task Force and took place in the Grand Hyatt Denver (37th floor ;-)). Luckily the weather was perfect, and the view of the landscape from the conference rooms was just amazing. I really enjoyed the time in Denver, as the organizer sdid all they could to treat the speaker well J. The talks were of mix of regular research or case-study type talks and some sponsored talks ranging from deployment experience, security and statistics to SDN (Yes, I said it ;)) and the Internet of Things (I said it again ;)). The line-up was nicely put together.

Chiron – An All-In-One IPv6 Penetration Testing Framework

Sat, 04 Oct 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis.

Last week I had the pleasure to give you my impressions regarding my experience about hacking for b33r at Ghent, that is, my participation at BruCON 2014 hacking conference. As I said among else, the reason that I was there was to present Chiron, my IPv6 penetration testing/security assessment framework, which was supported by the Brucon 5×5 program. The first version of Chiron had been presented at Troopers 14, during the IPv6 Security Summit.

Security Implications of Disruptive Technologies

Sat, 20 Sep 2014 00:00:00 +0000

Yesterday I gave a talk with the above title in a private setting. Given it might be of interest for some of you, the slides can be found here.

Have a great weekend everybody

Enno

MLD and Neighbor Discovery. Are They Related?

Wed, 03 Sep 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis.

Today we had the opportunity at ERNW to have a full-day discussion about MLD. The discussion was led by Jayson Salazar who writes his thesis on the topic.

For the newcomers to IPv6 world, the purpose of MLD, a subprotocol of IPv6, as defined in RFC 2710, is “to enable each IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes.” MLD was updated by MLDv2 in RFC 3810 in order to “add the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.”

Atomic Fragments vs. Fragmentation in the IPv6 “Real World”

Thu, 21 Aug 2014 00:00:00 +0000

This is a guest post by Antonios Atlasis.

Continuing the discussion about the IPv6 Atomic Fragments started at the IPv6 hacker’s mailing list and the freshly proposed draft RFC regarding the deprecation of the generation of IPv6 Atomic Fragments, we decided to check very quickly what is the current situation regarding the acceptance or the rejection of Atomic fragments in the “real world”. Thanks to Rafael Schaefer and the RISC lab at ERNW, we got some first measurements really fast.

Packet Too Big Messages and Atomic Fragments

Wed, 20 Aug 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis.

Taking the chance from a discussion on the IPv6 hacker’s mailing list and the freshly proposed draft RFC regarding the deprecation of the generation of IPv6 Atomic Fragments, I decided to test very quickly what is the current status related with the latest and some of the most poplar Operating Systems (OS) status (whether they send Atomic Fragments in response to Packet Too Big messages, or not). The motivation behind this was to check which one of them is potentially vulnerable to the DoS attack using the technique described in the above proposed RFC and taking it for granted that Atomic Fragments are blocked in the real world (but more about this, in another blogpost in the near future).

ERNW @BlackHat US 2014

Tue, 12 Aug 2014 00:00:00 +0000

Last week we had the opportunity and pleasure to present some of our research results at BlackHat US 2014 (besides of meeting a lot of old friends and having a great researchers’ dinner).

Enno and Antonios gave their presentation on IDPS evasion by IPv6 Extension Headers, described here.

The material can be found here: Slides, tools (the main tool used was Chiron, authored by Antonios) & whitepaper.

Ayhan and me presented our results of the security analysis of Cisco’s EnergyWise protocol. The protocol enables network-wide power monitoring and control (ie turning servers off or on, putting phones to standby — basically controlling the power state of all EnergyWise-enabled or PoE devices). The main problem (besides a DoS vulnerability we found in IOS, see official Cisco advisory) is its PSK-based authentication model, which enables an attacker to cause large-scale blackouts in data centers if the deployment is lacking certain controls (for example our good old favorite, segmentation…). There will be a longer blogpost/newsletter on this topic soon.
The material can be found here: Slides & tools

Evading IDPS by Combining IPv6 Extension Headers and Fragmentation “Features” – The Story of My Life…

Sat, 09 Aug 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis.

In the “A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices” blogpost I described a way to evade a high-end commercial IDPS device, the Tipping Point IDPS (TOS Tipping Point, Package 3.6.1.4036 and vaccine 3.2.0.8530 digital), by abusing a minor detail at the IPv6 specification. As I promised at the end of that blogpost, this is not the end. In this blogpost I am going to describe several new and different ways of evading another popular IDPS, an open-source one this time, Suricata.

IPv6 for Managers

Tue, 22 Jul 2014 00:00:00 +0000

We’re currently involved in a number of IPv6 activities in different organizations and one of the questions we are still facing – even in cases where there’s already a (in most cases networking team driven/originated) “project” (incl. budget, project sponsor, milestones etc.) – is along the lines of “How to sell IPv6 to our management?”.

In the following I will shortly lay out the line of reasoning and the terminology we usually employ for the task. Furthermore I’ve anonymized a presentation which we recently prepared as “input” for the network team of an enterprise organization; it can be found here. In case you want to get this as a PPT (for recyling purposes) pls send me a direct email (in exchange, we might ask you for a small donation of your will to the Troopers charity project… ).

IPv6 Requirements for Cloud Service Providers

Tue, 08 Jul 2014 00:00:00 +0000

Some weeks ago, at RIPE 68 in Warsaw, Sander Steffann gave a presentation about revising RIPE 554 which, in his own words, “is a template guideline for procurement of stuff that should do IPv6” (here’s the steganography transcript of the IPv6 working group session). Some of you will probably know RIPE 554 as a quite helpful document for identifying reasonable real-world requirements for IPv6 capable network devices (in particular at times when vendors quite willingly put an “IPv6 ready” sticker on all their gear…).

m0n0wall as an IPv6 firewall

Fri, 30 May 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis

Last October I had a quick look at pfSense 2.1 regarding the IPv6 support that it offers. It was the first stable support of pfSense that offered the capability for IPv6 network connectivity (a few comments about it can be found here). However, I knew that m0n0wall supported IPv6 quite a long time ago and that their developers had incorporated the support of IPv6 features which are not available in pfSense yet, so today I decided to have a look at it too.

A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices

Mon, 26 May 2014 00:00:00 +0000

(Or How the Smallest Detail Can Make a Difference)

This is a guest post from Antonios Atlasis.

As it is well known to the IPv6 enthusiasts, one of the most significant changes that IPv6 brings with it, apart from supporting a really huge address space, is the improved support for Extensions and Options, which is achieved by the usage of IPv6 Extension headers. According to RFC 2460, “changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.” So, by adding IPv6 Extension headers, according to the designers of the protocol, flexibility and efficiency in the IP layer is improved.

Microsoft Windows Update over IPv6 (or not?)

Wed, 21 May 2014 00:00:00 +0000

Hello everyone,

I recently stumbled over a document from Microsoft which lists all services/applications that support IPv6. Most of the content wasn’t new for me, but one item caught my attention. Windows Update. I haven’t heard before that Windows Update can be done over IPv6 (but this could just be me not looking hard enough ;)), so I was eager to test it out seeing if this is really the case. I was also curious why Microsoft referenced this document in the respective column.

IPv6 Address Plan Considerations, Part 3: The Plan ;-)

Wed, 14 May 2014 00:00:00 +0000

This is the third – and hence presumably last – part of the series of posts on IPv6 address planning (first part can be found here, second one here). It’s split into three main pieces. In the beginning I will lay out some general objectives to be considered when designing an address plan. Then I’ll have a look at potential hierarchy levels and finally I’ll discuss some real-life samples we’ve seen recently.

A Short Teaser on My New IPv6 Testing Framework

Fri, 21 Feb 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis

Hi,

my name is Antonios and I am an independent IT Security Researcher from Greece. One of my latest “hobbies” is IPv6 and its potential insecurities so, please let me talk to you about my latest experience on this.

This week, I had the opportunity to work together with the ERNW guys at their premises. They had built an IPv6 lab that included several commercial IPv6 security devices (firewalls, IDS/IPS and some high-end switches) and they kindly offered their lab to me to play with (thank you guys 🙂 – I always liked …expensive toys). The goal of this co-operation was two-fold: First, to test my new (not yet released) IPv6 pen-testing tool and secondly, to try to find out any IPv6-related security or operational issues on these devices (after all, they all claim that they are “IPv6-Ready”, right?).

Fresh Meat From the Coding Front

Thu, 20 Feb 2014 00:00:00 +0000

Within the last months I had some time to work on my code and today I’m releasing some of that: a new version of dizzy as well as two new loki modules.

New version of dizzy:

Download version 0.8.2 here.

USB target support

Dizzy is able to use neighbor travis’ facedancer to emulate a client device. Two fuzzing modes are available for USB descriptor fuzzing and USB endpoint fuzzing.

Here is an example cmd to start usb configuration descriptor fuzzing:

Configuring IPv6 Snooping and DHCPv6 Guard on Cisco IOS

Thu, 30 Jan 2014 00:00:00 +0000

Hi everyone,

Some of you may already know (the ones who are following Enno on Twitter) that Enno and I had our lab day in preparation for the IPv6 Security Summit at Troopers. We had a brand new and shiny Cat4948E as our lab device to do some testing of the current generation of Cisco’s IPv6 First Hop Security (FHS) mechanisms. The Catalyst was running the latest image available (15.1(2)SG3).

In this small blog post, we will take a look at the configuration and behavior of IPv6 Snooping and DHCPv6 Guard. So let’s start with IPv6 Snooping:

IPv6 Address Plan Considerations, Part 2: The “PI Space from (Single|Multiple) RIR(s) Debate”

Thu, 23 Jan 2014 00:00:00 +0000

This is the second part of the – presumably – three-part series on IPv6 address planning which I started here.

Before an enterprise organization (strictly speaking “their internal service provider acting as LIR”, as laid out in the first part) starts assigning prefix[es]/lengths to their networks usually another discussion has to be undertaken & solved: “go with one /32 [PI space] from one RIR or apply for /32s from several RIRs”.

IPv6 Address Plan Considerations, Part 1: General Guidelines

Fri, 10 Jan 2014 00:00:00 +0000

In an upcoming series of blog posts I will discuss some principles & considerations on developing an IPv6 address plan. In (hopefully) rather quick succession there will be three posts:

the first on some general rules as for IPv6 address planning which we regard instrumental in the process.
the second covering the “PI space from a single RIR or PI space from each (relevant, as for $ORG) RIR?” debate.
the third on actual approaches to structuring/grouping each region’s /32 (or /36) into subdivisions like sites, VRFs, facilities, use types, buildings, whatever. I understand that this part is probably the one quite some readers are most interested in; still for a reasonable line of thought the others have to be covered in advance.

As you might have already spotted from the prefix lengths mentioned above, the presumed setting (read: the main audience) of this piece is a sufficiently large enterprise organization with sites/subsidiaries/plants all over the globe, potentially mainly in the EMEA, APAC and Americas regions. So if you’re [with] a service provider organization, a university or small[er] organization, some of the recommendations I lay out might not apply to you. This focus (or restriction thereof) is for the simple reason of ignorance. Given I haven’t been involved in many address planning efforts in such organizations I don’t feel qualified to advance opinions on their settings.

Design & Configuration of IPv6 Segments with High Security Requirements

Fri, 13 Dec 2013 00:00:00 +0000

Such was the title of a talk I gave yesterday at ACSAC 29. It was an updated and shortened version of a similar talk I had given at the Troopers IPv6 Security Summit (btw: this is the preliminary agenda of the 2014 event).

The slides of the ACSAC talk can be found here.

have a great weekend everybody

Enno

IPv6 Scanner

Sat, 09 Nov 2013 00:00:00 +0000

This is a guest post from Antonios Atlasis.

===

Having just finished the second “Advanced Attack Techniques against IPv6 Networks” workshop (some of the course material can be found here), organised and hosted by ERNW and their partner HM Training Solutions, I would like to take this opportunity to release publicly one of my scripting tools, an IPv6 scanner. This tool is based on Scapy (so you have to install Scapy and its prerequisites before using it). It should not be considered as a replacement or a competitor of nmap against IPv6 or of the scanners incorporated into the great IPv6 toolkits already released by Marc Heuse and Fernando Gont, but, instead, as a tool released mainly for educational purposes. Specifically, this scanner, apart from supporting some of the most well known port scanning techniques, from ping scanning to SYN, RESET, ACK, XMAS, etc., etc., TCP or UDP scanning, it also combines, by using the suitable switches, some IDS/IPS evasion techniques. As I have found out up to now, at least two of them, if used “properly”, can be effective against a very popular IDS/IPS software used by many “Fortune 100” companies out there. This means that you can launch actually any type of the supported network-scanning techniques while flying under the radar of this specific IDS software (and perhaps some other too, who knows…). But first of all, as always please check the corresponding README file.

IPAM Requirements in IPv6 Networks

Thu, 24 Oct 2013 00:00:00 +0000

I recently had a discussion with some practitioners about requirements to IP Address Management (IPAM) solutions which are specific for IPv6 networks. We came up with the following:

Mandatory: Track all dynamic IPv6 assignments (SLAAC + PrivExtensions, DHCP etc.), by polling neighbor caches from network devices. Support SNMPv3 for this task.
Optional (read: nice-to-have): support other methods than SNMP to gather this info (e.g. SSH-ing into devices and execution of appropriate “show” commands).

IPv6 Hackers Meeting @ IETF 87 in Berlin / Slides

Thu, 01 Aug 2013 00:00:00 +0000

That meeting was actually a great event. Once more, big thanks! to Fernando for organizing it and to EANTC for providing the logistics.
A couple of unordered notes to follow:

a) The slides of our contribution can be found here. Again, pls note that this is work in progress and we’re happy to receive any kind of feedback.
[given Fernando explicitly mentioned Troopers, we’ve allowed ourselves to put some reference to it into this version of the slide deck…]

IPv6 Hackers Meeting @ IETF 87, Berlin

Fri, 26 Jul 2013 00:00:00 +0000

Next to IETF 87 going on in Berlin in a few days there will be an informal meeting of the “IPv6 Hackers” on Tuesday. We really look forward to personally meet a number of people who we (so far) only know from the associated mailing list or similar machine-enhanced exchange. We hope to contribute as well. Based on the stuff of this workshop from the IPv6 Security Summit at Troopers13 we might give a short project presentation along the lines of “Some Notes on Testing the Real-World IPv6 Capabilities of Commercial Security Products”, providing an overview of some testing done on commercial gear, together with a discussion of testing approaches, tools and key aspects.

Slides & Scripts from Antonios Atlasis’ “Advanced Attack Techniques against IPv6 Networks” Workshop

Tue, 25 Jun 2013 00:00:00 +0000

After his great presentations on IPv6 Extensions Headers and security problems related to fragmentation we had invited Antonios Atlasis to Heidelberg to give this workshop at ERNW. It was a great experience with many fruitful discussions between the participants (mostly security practitioners from very large organizations planning to have their Internet edge IPv6 enabled within the next 6-12 months) and him/us. Antonios thankfully decided to make his slides and scripts available for those interested in further research on the topics (it should be noted that the scripts have not been tested thoroughly and he’s happy to receive feedback of any kind at antoniosDOTatlasisDOTgmailDOTcom). Today Marc (Heuse) gives his workshop on pentesting in the IPv6 age. Hopefully such events help to move things into the right direction in the IPv6 security space…

RA Guard (Evasion) – We Stand Corrected

Mon, 20 May 2013 00:00:00 +0000

Recently Jozef Pivarník and Matěj Grégr published an excellent write-up on RA Guard & evasion techniques. Amongst others they tested the “undetermined-transport” ACL we described here and here. As it turns out the “workaround” for implementing undetermined-transport on platforms seemingly not supporting it, causes some bad collateral damage: the respective port does not forward any IPv6 packets any more (this was brought to my attention by Roberto Taccon). We had done some tests after applying it (by means of the “workaround”) but we had just looked at fragmented RA packets (which did not get through => test succeeded). So, frankly: the undetermined-transport trick does not make sense at all on the “unsupported platforms”…

IPv6 Attacks & Pentesting Workshops

Tue, 14 May 2013 00:00:00 +0000

Due to “popular demand” and given Marc couldn’t join us at the IPv6 Security Summit (as flights into FRA were canceled that day due to snow) we decided to invite him and Antonios Atlasis another time, to present their knowledge, skills & voodoo in two workshops held in Heidelberg, in late June. More details can be found here.

See you all potentially at the Heise IPv6 Kongress, take care

Enno

RA Guard Support

Thu, 02 May 2013 00:00:00 +0000

Hi,

on the [ipv6-ops] mailing list currently there’s some discussion about RA guard support on switches from different vendors.

Stefan, one of our students (btw: working on a topic similar to this session), quickly put together a preliminary list, based on publicly available information (read: the WWW ;-)). Some of you may find this useful; it can be found here. Furthermore on the list this link was mentioned which seems to provide some info as well (albeit potentially not very up-to-date).

Some more Notes on RA Guard Evasion and “undetermined-transport”

Sat, 13 Apr 2013 00:00:00 +0000

I just had an interesting discussion with Jim Small (who gives the “IPv6 Attacks and Countermeasures” talk at the North American IPv6 Summit next week) about the feasibility of the “undetermined-transport” keyword in PACLs on Cisco 3560 switches (here running IOS 15.0(2)SE). Actually there’s some kind-of funny behavior as for it on that platform (and there’s even some Cisco documentation stating it’s not supported). Let’s have a look, and start with a quick refresher.

Troopers13 IPv6 Security Summit – First Presentations Available

Mon, 11 Mar 2013 00:00:00 +0000

We had a great day today at the Troopers IPv6 Security Summit. Good conversations, quite some technical discussion and a prevailing overall will to improve actual IPv6 network security.

Here are the slides of Antonios Atlasis’ great talk on extension headers and these are some of his accompanying Python/Scapy scripts. My own presentation on high secure IPv6 networks can be found here. The slides of the real-world capabilities workshop will not be published yet as we first have to discuss some stuff with a vendor.

IPv6 Neighbor Cache Exhaustion Attacks – Risk Assessment & Mitigation Strategies, Part 1

Tue, 05 Mar 2013 00:00:00 +0000

Recently there has been quite some discussion about so-called neighbor cache exhaustion (“NCE”) attacks in the IPv6 world. This is Jeff Wheeler’s “classic paper” on the subject, my kind-of personal networking guru Ivan Pepelnjak blogged about it back some time, here‘s a related discussion on the IPv6 hackers mailing list and in March 2012 (only three months after the respective IETF draft’s version 0 was released) the RFC 6583 was published, covering various protection strategies.

IPv6 Security Problems Related to Extension Headers & Fragmentation

Mon, 04 Mar 2013 00:00:00 +0000

Marc Heuse – who happens to give this workshop at the Troopers IPv6 Security Summit next week – just sent this email (subject: “Remote system freeze thanks to Kaspersky Internet Security 2013”) to the IPv6 hackers mailing list, describing how a system running a certain flavor of Kaspersky security products can be remotely frozen when receiving IPv6 packets with a specific combination of extension headers and fragmentation (which in turn can be easily generated by his IPv6 protocol attack suite).

IPv6 Extension Headers: New Features, and New Attack Vectors

Sun, 17 Feb 2013 00:00:00 +0000

This is a guest post from Antonios Atlasis

IPv6 introduces a lot of new features and consequently, a lot of new capabilities. Obviously, the most significant of them is the huge address space that it offers. However, this is not the only one. IPv6 also introduces the use of the IPv6 Extension Headers. The IPv6 header has been considerably simplified in comparison with IPv4 one. On the other hand, the IPv6 Extension Headers, not only do the “job” of most of the fields which were removed from the main header, but, additionally, they add many more. However, any new “technology” creates new attack opportunities and a “new” protocol, such as IPv6 could not be an exception, especially since its design and implementation is more complicated than it’s predecessor.

TROOPERS13: TelcoSecDay, IPv6 Security Summit and some more Updates

Sat, 02 Feb 2013 00:00:00 +0000

Here’s a number of updates as for upcoming TROOPERS13.

The preliminary agenda for this year’s TelcoSecDay can be found here.

Here‘s the (again: preliminary) agenda of the IPv6 Security Summit.

Last, but not least we’ve included another four talks in the main conference:

======

Sergey Bratus & Travis Goodspeed: You wouldn’t share a syringe. Would you share a USB port?

Synopsis: Previous work has shown that a USB port left unattended may be subject to pwnage via insertion of a device that types into your command shell (e.g. here). Impressive attack payloads have been delivered over USB to jailbreak PS3 and a “smart TV“. Not surprisingly, USB stacks started incorporating defenses such as device registration, USB firewalls, and other protective kits. But do these protective measures go far enough to let you safely plug in a strange thumb drive into your laptop’s USB port?

Fragmentation (overlapping) attacks in IPv6. Have we learned our lesson, yet?

Tue, 29 Jan 2013 00:00:00 +0000

This is a guest post from Antonios Atlasis

It has been a year since fragmentation attacks in IPv6 were last examined publicly (in Black Hat Europe 2012). Issues well known from the IPv4 era appeared again in IPv6. Surprisingly enough, some of the most popular Operating Systems (OS), included ones considered “secure”, were proven to be vulnerable to such attacks, although fragmentation overlapping is strictly forbidden in IPv6 since 2009 (RFC5722). Some other OS, although in a better shape, still appeared to have some issues in specific cases.

A First Glance – RA Guard Support in Hyper-V 3.0

Tue, 24 Jul 2012 00:00:00 +0000

Last week I read about the new networking features of the integrated vSwitch of Hyper-V 3.0. I was quite surprised that RA Guard will be natively supported and was curious about implementation and functionality. If you don’t know how RA Guard works, I recommend reading our previous blog posts here, here, here, here and here, or have a look at our workshop at Troopers12.

I downloaded Windows Server 2012 RC to do some practical testing. Since my girlfriend was working the whole weekend, I had plenty of time to play around with all that stuff without risking trouble 😉

IPv6 Privacy Extensions

Mon, 14 May 2012 00:00:00 +0000

Last week Christopher Werny and I gave a talk on IPv6 Privacy Extensions at the Heise IPv6 Kongress. As our slides were not included in the event’s material here’s the presentation’s slide deck.

As in 2011 we really liked the conference; there was a number of interesting talks and we met quite some fellows from the IPv6 security space. Btw: we plan to organize a dedicated IPv6 security summit in late 2012 (probably on 6th and 7th of November) in Heidelberg, similar to the Telco Sec Day at Troopers. We’ll annouce details as for this one in some weeks.

The Story Continues – Another IPv6 Update

Fri, 30 Mar 2012 00:00:00 +0000

TROOPERS12 came to an end last week on Friday; needless to say it was an awesome event. 😉
The first two days offered workshops on various topics. On Monday Enno, Marc “Van Hauser” Heuse and I gave a one day workshop on “Advanced IPv6 Security”. I think attendees as well as trainers had a real good time during and after the workshop fiddling around with IPv6. Especially Marc had quite some fun as he discovered that we provided “global” IPv6 Connectivity for the conference network, and according to one of his tweets, TROOPERS12 was the first security conference he visited, offering this kind of connectivity.

Yet another update on IPv6 security – Some notes from the IPv6-Kongress in Frankfurt

Mon, 16 May 2011 00:00:00 +0000

A couple of hours ago Christopher (Werny) and I gave this presentation at the Heise IPv6-Kongress, which overall was a quite interesting and well-organized event bringing together a number of practitioners from the field. While yesterday’s talks were dominated by a certain euphoria and optimistic pioneer spirit, the second day featured some security talks which induced slight shadows to the brave new world of IPv6 ;-). I particularly enjoyed meeting Eric Vyncke from Cisco (one of the two authors of this great book) and Marc “van Hauser” Heuse who released a new version of the THC-IPV6 tool set today. We had some fruitful discussions and we took the opportunity to test some of his newly implemented attacks against “RA Guard” running on a 4948E Chris and I had brought for a demo within our talk. Unfortunately – or fortunately in terms of a “from theory to reality” approach – I have to say that Marc found a quite clever way to circumvent RA Guard by putting the actual “RA payload” into a second frame following a first one mostly containing a “long & empty” destination option (after a fragmentation header pointing to the mentioned second one). To get an idea pls see these screenshots from Wireshark.

IPv6 Security ‒ The Story Continues

Wed, 09 Mar 2011 00:00:00 +0000

Just a short addition to the previous posts ([1], [2]) on IPv6 security today. In the last two days I had the opportunity to sharpen my understanding of some aspects of IPv6 behavior in (Windows-) LANs. Actually I gave an IPv6 workshop for some members of the “Project Services” team of Hamburg-based computer & competence IT-solutions provider [btw: thanks to Mr. Wendler of CuC for organizing it, and thanks to Mr. Cassel for the breakfast…].

IPv6 Security Part 2, RA Guard – Let’s get practical

Sat, 05 Mar 2011 00:00:00 +0000

Hi everybody,

this post is the sequel of this one on the IPv6 security feature called “RA guard”. As announced in that post I recently got a 4948 on ebay. After installing the appropriate image and noticing that RA guard was still unavailable I found out it should have been a 4948E which is capable of “doing IPv6 in hardware” (as opposed to the “simple 4948” only supporting IPv6 in a “software switched” way. and pls note there’s also the informal term 4948-E denoting a 4948 running an “enhanced image”).

IPv6 Security Part 1, RA Guard – The Theory

Wed, 05 Jan 2011 00:00:00 +0000

Hi,

at first a happy new year to our loyal readers (and, of course, to everybody else too ;-)! We hope you all had some pleasant transition times, not suffering from bad hangovers after 27C3 or sth 😉

Things are heating up for Troopers and in the course of that we started putting together the slides for the workshops (I’m delighted that Flo told me today there’s already quite a number of bookings for the workshops…). I myself will give the “IPv6 Security in LANs” workshop, together with Christopher. The workshop preparation will be accompanied by a series of blogposts with three main areas to be covered: