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.
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:
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.
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.
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:
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.
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.
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.
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.
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).
In November 2014, after quite some controversy in the IETF OPSEC working group (for those interested look at the archives), the InformationalRFC 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.
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.