TAG | IPv6
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.
0 Comments | Posted by Enno Rey
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.
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 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:
This is a guest post from Antonios Atlasis.
On Thursday the 20th 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).
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.
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”?
1 Comment | Posted by Enno Rey
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.
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.
4 Comments | Posted by Enno Rey
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.
At the end of the first part we had a configuration state which led to two global addresses on both systems involved, a DHCPv6 provided one and another one generated as part of the SLAAC process, which can create operational issues of all kinds (improper source address selection, hindered troubleshooting etc.). Furthermore such a setting does not reflect “the operational DHCPv4 model” which we envisaged as the ultimate goal of our exercise. I had finished that post along the lines: “we then have to get rid of the SLAAC address”.