Although a bit on short notice it was a good meeting with interesting
discussions. I contributed with shortened versions of two talks we had delivered
in the past:
the “MLD Considered Harmful” talk that Antonios,
Jayson and I had presented at the
Troopers IPv6 Security Summit 2015.
The mentioned Internet-Draft on MLD security which
Eric Vyncke, Antonios and myself are
working on can be
found here.
We’re happy to receive any feedback on that one.
Special thanks go to
Jan Zorz
and to CZ.NIC for hosting us and providing refreshments.
Much appreciated, guys!
When we wrote our initial blogpost regarding the
evasion of Cisco ACLs by (Ab)Using IPv6,
where we described
(known to Cisco)
cases of Access Control Lists (ACL) circumvention, we also suggested some
mitigation techniques including the blocking of some (if not all) IPv6 Extension
Headers.
Almost a month later, we got
a comment
from Matej Gregr that, even if the ACLs of certain Cisco Switches are
configured to block IPv6 Extension headers like Hop-by-Hop or Destination
Options headers, this does not actually happen/work as expected. Of course this
made us re-visit the lab in the interim ;-).
I recently had the pleasure to join the
64th NANOG (North American Network
Operators’ Group) meeting in San Francisco, which can be understood as one of
the largest Internet engineering conferences at all. It takes place three times
a year at different locations in North America.
What I personally like about NANOG is its strong collaborative and cooperative
character. It is not about single persons and also not too much about
spectacular projects but more about discussing technologies, ideas, challenges
and numbers. Every talk has a comparatively large time slot reserved for
discussion, which is often more than fully used. Discussion is typically
actively focused and is more time-consuming (and even more relevant) than the
talk itself. Which often is intended by the community. The climate of discussion
is almost always impressively polite and constructive, even for controversially
discussed topics.
In the course of a customer project I recently documented some thoughts and
general objectives of IPv6 address planning, expanding on stuff I wrote a while
ago in the
series on “Address Plan Considerations”.
An excerpt of that (newer) document
can be found here.
Due to the context it originates from it’s in German, still I hope it’s useful
for some readers.
If you’re interested in the topic it might be a good idea to listen to
Tom Coffeen‘s talk at the upcoming
IPv6 Business Conference, too.
“The security of IPv4 is roughly equivalent to IPv6. So why do we expect more
from IPv6?”
While I highly value Scott’s IPv6 expertise – not least because I learned a lot
about IPv6 security from
the book on the topic
he wrote together with Eric Vyncke – I
strongly disagree with his statement, mainly with the first part. In this post I
will lay out why I think that IPv6 is actually less secure than IPv4.
IPv6 is often called a “complex protocol”, not least by myself (for example in
my
keynote to the IPv6 Security Summit 2014). In
this post I want to have a quick look at three questions:
– Can IPv6 be considered a “complex protocol”?
– Is it “more complex” than IPv4?
– Can we expect IPv6 networks to be “complex networks”?
I’d like to start with some clarifications and a definition. First of all: when
I discuss IPv6 “as a protocol”, this actually means “the IPv6 procotol family”
incl. those helper protocols needed to support (“core”) IPv6 in performing
properly in most networks, like ICMPv6 and MLD.
Then, of course, we have to define the term “complexity”, which is a difficult
task in itself. [MITCHELL2009] gives an overview of several potential
(definition) approaches in a dedicated chapter and the same undertaking is
performed – in quite different ways – by most of the authors of individual
contributions to [PELITI1988].
Two weeks ago Christopher and I joined the RIPE70 meeting in Amsterdam. Being
part of the group was fun as always and we had quite some interesting
conversations with peers from the IPv6 community.
We could even contribute a bit to some discussions, with two talks. I gave one
titled “Will It Be Routed? – On IPv6 Address Space Allocation & Assignment
Approaches in Very Large Organizations” in the Address Policy Working Group
session on Wednesday. This is the abstract:
On March 16^(th), 2015, at the Troopers
IPv6 Security Summit,
we finally released the SI6 Networks’ IPv6 Toolkit v2.0 (Guille). The
aforementioned release is now available at the
SI6 IPv6 Toolkit homepage. It is
the result of over a year of work, and includes improvements in the following
areas:
Increased portability
Bug fixes
Additional features in existing tools
Brand-new tools
Increased Portability
One of the goals that the SI6 Toolkit had since its inception is that of
portability. The SI6 Toolkit has supported all major BSD-derived OSes, Linux,
and Mac OS for a number of years now. And this new release supports yet another
new platform: OpenSolaris. We believe that besides supporting a greater user
base, increased portability ultimately results in improved code quality.
The purpose of this blog post is to elucidate how and why MLD, an IPv6 protocol
we’ve been lately talking quite a bit about, is an unnecessarily complex beast
. This article should also serve to summarize a couple of points we’ve mentioned
during our talks about MLD but which because of time constraints never make it
into the main discussion. We’ve talked about
other aspects of MLD in previous posts.
So, have a look at those if this is a topic which you find interesting. Without
further ado, let’s start for today.