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.
Continue readingBuilding
What to Do Today if You Want to Deploy IPv6 Tomorrow
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
Continue readingHow to go ahead with future end of life Windows (2003) Servers
Server operating systems with an OS, for which vendor support has ended, come with many risks that have to be considered and addressed. The primary goal should be always to decommission or migrate the majority of end-of-life (EoL) servers to OS versions, supported by the vendor. Here it should be noted that a migration to an up-to-date OS should be preferably done before your organization enters the end of life of that software 😉
Continue readingIPv6-related Requirements for Security Devices
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.
Continue readingIPv6 Hardening Guide for OS X
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.
Continue readingIs RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6
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 ;-).
Continue readingUsing Android without Google, Part 1
We’re using our smart phones every day to manage contacts, calendar entries, e-mail, and social communication (please note that we at ERNW still have a strict “no company data on smartphones/tablets” – which includes email). Everything is easy to use and automated syncing provides access to our data from anywhere. Data is stored in most cases on premises of a cloud service provided by the OS vendor of your smart phone – mostly Google, Apple or Microsoft. You don’t need to pay for this service – and the cloud provider could use your data for personalization and service improvements.
Continue readingIPv6-related Requirements for the Internet Uplink or MPLS Networks
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:
Continue readingEvaluation of IPv6 Capabilities of Commercial IPAM Solutions
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.
The Persistent Problem of State in IPv6 (Security)
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.