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
Continue readingLast 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).
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:
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:
These were my own contributions:
Continue reading Continue readingGiven the CfP for Black Hat US in Vegas ends in a few days – and as apparently some people have already started to think about their TR18 submissions – I’ll quickly provide some loose recommendations on how to write a submission here. There’s quite some reasonable advice out there already (the BH CfP site lists this and this which you should both read as well) but some of you might find it useful to get (yet) another perspective.
Continue reading Continue readingIn 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:
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.
Continue reading Continue readingIn 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:
Version
Continue reading Continue readingIn 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:
Continue reading Continue readingThis is the 3rd part of this loose series on considerations of (operating) DMZs
in 2016 (part 1 on the role of a DMZ is can be found
here,
part 2 on reverse proxies
here).
Again,
I dare to deviate a bit from the plan & order I initially had in mind – today I
will cover one process whose maturity may significantly influence the overall
security posture of a DMZ environment: firewall rule management.
How to provide updates to IoT devices – yes, I’m aware this might be a overly
broad generalization for many different devices – has been the topic of many
discussions in the last years (for those interested the papers from the
“Internet of Things Software Update Workshop (IoTSU)”
might be a good starting point).
Given Matthias and I will moderate the respective session at tomorrow’s
IoT Insight Summit
I started writing down some points that we consider relevant in this context.