today we want to examine the behavior of Cisco devices when they receive spoofed
IPv6 Neighbor Advertisement packets from an untrusted system pretending to be
the default router for the local segment. We start with a quick refresher how
Cisco devices behave in the legacy (IPv4) world when they receive a spoofed
broadcast ARP packet containing the IP address of the device but with a
different MAC address, followed by a discussion of the corresponding behavior in
the IPv6 world.
I had the pleasure to sit in Mark Townsley
“Addressing Networking Challenges With Latest Innovations in IPv6”
session at Cisco Live yesterday and – somewhat inevitably – there was a mention
of Facebook having implemented an IPv6-only approach in their data centers
(here’s a talk from Paul Saab/FB
laying out details). So, with the
“IPv6 Panel” looming,
I started reflecting on “Why don’t we see this in our customer space?”. This
post quickly summarizes some observations and thoughts.
Enno and I spent the first day on Cisco Live Europe in Berlin today attending
the “Advanced Practical Knowledge for Enterprise Deploying IPv6” technical
breakout held by Tim Martin and
Jim Bailey.
It was a good breakout session, and thanks again Tim for the honorable mention
of our work in your slides! We really appreciate it. Like
last year,
we were curious how the Wifi network was setup this year as I face a
corresponding task for Troopers in March,
with some
major changes
in comparison to the last years. The Wifi infastructure in Berlin looked very
similar to the one from last year in Milan, we had the “standard” Cisco Live
SSID as well as an IPv6-only (with NAT64 as translation mechanism) SSID. The
standard SSID looked identical to last year with the exception that now the
RA Throttling
feature on the WLC was active from the beginning! Neither the M nor the O flag
are set which means that my client has to use the legacy protocol to resolve
AAAA records. As I am running Windows, it does not support
RA option 25 but the option wasn’t
included in the RAs anyway. The preference was configured to the default
“medium”. One thing I noticed, but haven’t had a chance to ask
Andrew Yourtchenko, was that for the legacy
(IPv4) connection they use HSRPv2 as an FHRP protocol (indicated by the MAC
address
00:00:0c:9f:f0:01
I received from the gateway) but for IPv6 I received Router Advertisements from
two different MAC addresses (which both belong to Cisco, so I don’t think anyone
sent spoofed RAs). I am curious about the reasoning for this approach 🙂
What i also encountered was that the Peer-to-Peer Blocking feature was
apparently not enabled on the SSID as I was able to enumerate approx. 1600
active clients at the time. No worries, I haven’t done anything else, just was
curious whether the feature was activated or not…
I’ll be on the
“IPv6 Panel”
at Cisco Live next week and somewhat in
preparation I started thinking about what we currently see when it comes to IPv6
deployment in our customer space. We notably observe a large gap between
“textbook planning & transition strategies” and what’s happening in real-life in
those organizations. I hence decided to write down some of these observations in
a quick series of posts to be published in the upcoming days and, maybe more
importantly, to reflect on the reasoning of this apparent mismatch between
theory and practice. I dare to add a dose of devil’s advocate here+there…
For today let’s start with some comments on IPv6 address planning.
It’s me again with another teaser for an upcoming workshop at the
IPv6 Security Summit. This one
is a classic! If you happen to deploy IPv6 in your environment in the near
future, but didn’t had the time to think about the security implications, this
workshop
is the right place to start.
We will start the workshop with a quick refresher of the core behavior of IPv6
to make sure that every attendee is on the same page. Before we start discussing
and demonstrating various IPv6 attacks, we dive into (a little more abstract)
topic of why IPv6 security actually isn’t that easy to implement. We will
continue with IPv6 attacks targeted at the local link. Rafael and I will
introduce commonly used IPv6 attack tools as well as performing various attacks
in a dedicated lab environment. Every attendee is encouraged to participate in
these exercises. We will provide you with the necessary tools; you just have to
bring a laptop with (ideally) Linux installed. We will prepare some virtual
machines including VMware Player in case your corporate laptop runs Windows.
today I want to talk about OSPFv3. I won’t cover the glory details of
OSPFv3, there are smarter guys than me out
there who did that
already 😉 and
there are great resources to familiarize yourself with the protocol. However, it
should be noted that OSPFv3 is not only OSPF for IPv6, OSPFv3 brought some major
enhancements compared to OSPFv2. Wouldn’t it be cool to benefit from the
enhancements in the IPv4 world as well?
Today I want to give you a little teaser about my upcoming talk at the
IPv6 Security Summit about
First-Hop-Security on HP devices. In the past I presented on about
First-Hop-Security in the
Cisco realm and
in virtualized environments.
Until recently, Cisco was mostly the only vendor who had a sufficient
implementation of various IPv6 security features on their access-layer switches,
but HP closed the gap considerably and it’s time to have an in-depth look
at their implementation of those features.
some of you may have seen my last
blog post
about the preparation of the Troopers network. Today I want to give you a little
teaser on what to expect for the
talk
I will present during the IPv6 Security Summit. As the title implies, it’s not
only about building a secure IPv6 WiFi, but also a reliable one. One might think
that there aren’t many differences in comparison to IPv4, but the heavy reliance
on multicast of IPv6 does have implications for Wi-Fi networks in general.
I am currently preparing the Troopers network in a
lab environment to ensure that we all will have a smooth Wi-Fi experience during
Troopers. I wanted to spice things up a little bit for the Wi-Fi deployment
(more on that in a following blogpost) and get rid of IPv4 wherever possible.
Our Wi-Fi infrastructure consists of typical Cisco Access Points (1602) and a
2504 Wireless LAN Controller. Beginning with WLC image 8.0 it is finally
supported to establish the CAPWAP tunnel between the AP and the WLC over IPv6,
which is awesome and I wanted to implement it right away.
In this part of the series (for the other parts see
[1],
[2],
[3],
[4],
[5]) we’ll
discuss approaches to implement security measures suited to protect from
IPv6-related threats on the host level.
These can be grouped into the following generic categories each of which will be
described in more detail in the following:
“Minimal machine” approach
Static configuration of IPv6 parameters
Tweaking the behavior of IPv6-related mechanisms/protocols
Local packet filtering
Some of you might recall that we published IPv6 hardening guides for both
Linux
and
Windows a
while ago and we’ll reference those exact documents below, by [Hard_Linux]
and [Hard_Windows] respectively.