We’re currently involved in a number of IPv6 activities in different
organizations and one of the questions we are still facing – even in cases where
there’s already a (in most cases networking team driven/originated) “project”
(incl. budget, project sponsor, milestones etc.) – is along the lines of “How to
sell IPv6 to our management?”.
In the following I will shortly lay out the line of reasoning and the
terminology we usually employ for the task. Furthermore I’ve anonymized a
presentation which we recently prepared as “input” for the network team of an
enterprise organization;
it can be found here. In
case you want to get this as a PPT (for recyling purposes) pls send me a direct
email (in exchange, we might ask you for a small donation of your will to the
Troopers charity project…
).
Some weeks ago, at RIPE 68 in Warsaw,
Sander Steffann gave a
presentation about revising RIPE 554
which, in his own words, “is a template guideline for procurement of stuff that
should do IPv6” (here’s the
steganography transcript of the IPv6 working group session). Some of you will
probably know RIPE 554 as a quite
helpful document for identifying reasonable real-world requirements for IPv6
capable network devices (in particular at times when vendors quite willingly put
an “IPv6 ready” sticker on all their gear…).
Last October I had a quick look at pfSense 2.1
regarding the IPv6 support that it offers. It was the first stable support of
pfSense that offered the capability for IPv6 network connectivity (a few
comments about it can be found
here). However,
I knew that m0n0wall supported IPv6 quite a long time
ago and that their developers had incorporated the support of IPv6 features
which are not available in pfSense yet, so today I decided to have a look at it
too.
As it is well known to the IPv6 enthusiasts, one of the most significant changes
that IPv6 brings with it, apart from supporting a really huge address space, is
the improved support for Extensions and Options, which is achieved by the usage
of IPv6 Extension headers. According to
RFC 2460, “changes in the way IP
header options are encoded allows for more efficient forwarding, less stringent
limits on the length of options, and greater flexibility for introducing new
options in the future.” So, by adding IPv6 Extension headers, according to the
designers of the protocol, flexibility and efficiency in the IP layer is
improved.
This is the third – and hence presumably last – part of the series of posts on
IPv6 address planning (first part can be found
here,
second one
here).
It’s split into three main pieces. In the beginning I will lay out some general
objectives to be considered when designing an address plan. Then I’ll have a
look at potential hierarchy levels and finally I’ll discuss some real-life
samples we’ve seen recently.
This is a guest post from Vladimir Wolstencroft from our friends of
aura information security
==================================================================
Mobile messaging applications have been occupying people’s attention and
it seems to be all the latest news. Perhaps I should have called my presentation
the 19 Billion dollar app but at the time of writing and research I thought the
proposed 3 Billion dollar amount for SnapChat was a little ludicrous, who could
have known that would have been just a drop in the ocean.
my name is Antonios and I am an independent IT Security Researcher from Greece.
One of my latest “hobbies” is IPv6 and its potential insecurities so, please let
me talk to you about my latest experience on this.
This week, I had the opportunity to work together with the ERNW guys at their
premises. They had built an IPv6 lab that included several commercial IPv6
security devices (firewalls, IDS/IPS and some high-end switches) and they kindly
offered their lab to me to play with (thank you guys 🙂 – I always liked
…expensive toys). The goal of this co-operation was two-fold: First, to test my
new (not yet released) IPv6 pen-testing tool and secondly, to try to find out
any IPv6-related security or operational issues on these devices (after all,
they all claim that they are “IPv6-Ready”, right?).
Given we’ve received a number of inquiries as for the agenda of this year’s
TelcoSecDay here’s a first preliminary agenda. To get an idea of the event’s
character you might have a look at the agenda of the
2012 edition
or the
2013 edition.
Pls note that there might be changes/additions to the following outline as we’re
currently discussing potential contributions with two European operators. Here
we go, for today:
9:00: Opening Remarks & Introduction
9:15: Ravi Borgaonkor – Evolution of SIM Card Security
10:15: Break
10:45: Adrian Dabrowski
11:45: Collin Mulliner – PatchDroid – Third Party Security Patches for Android
12:30: Lunch
13:45: Philippe Langlois
14:45: Break
15:15: Haya Shulman – The Illusion of Challenge-Response Authentication
16:00: Christian Sielaff & Daniel Hauenstein – Breaking Network Monitoring Tools
Used in Telco Space
16:30: Closing Remarks
19:00: Joint dinner (hosted by ERNW) in Heidelberg Altstadt for those interested
and/or staying for the main conference
This is the second part of the – presumably – three-part series on IPv6 address
planning which I started
here.
Before an enterprise organization (strictly speaking “their internal service
provider acting as LIR”, as laid out in the first part) starts assigning
prefix[es]/lengths to their networks usually another discussion has to be
undertaken & solved: “go with one /32 [PI space] from one RIR or apply for
/32s from several RIRs”.