Bold Statements
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
Continue readingWhen 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.
Continue reading “Security Implications of Using IPv6 GUAs Only”
Continue readingIn 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:
Continue reading “IPv6 in RFIs/Tendering Processes”
Continue readingThis 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).
Continue reading “MLD Considered Harmful?”
Continue readingThis 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:
Continue reading “MLD to Be Reconsidered?”
Continue readingNext 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”?
Continue reading “Protocol Properties & Attack Vectors”
Continue readingTo 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.
Best
Enno
Continue readingIf 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
Continue readingThis 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”.
Continue reading “Router Advertisement Options to the Rescue – A Deep Dive into DHCPv6, Part 2”
Continue readingProbably 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.
Continue reading “I Don’t Have Any Neighbors – A Deep Dive into DHCPv6, Part 1”
Continue reading