In an upcoming series of blog posts I will discuss some principles &
considerations on developing an IPv6 address plan. In (hopefully) rather quick
succession there will be three posts:
the first on some general rules as for IPv6 address planning which we regard
instrumental in the process.
the second covering the “PI space from a single RIR or PI space from each
(relevant, as for $ORG) RIR?” debate.
the third on actual approaches to structuring/grouping each region’s /32 (or
/36) into subdivisions like sites, VRFs, facilities, use types, buildings,
whatever. I understand that this part is probably the one quite some readers
are most interested in; still for a reasonable line of thought the others have
to be covered in advance.
As you might have already spotted from the prefix lengths mentioned above, the
presumed setting (read: the main audience) of this piece is a sufficiently large
enterprise organization with sites/subsidiaries/plants all over the globe,
potentially mainly in the EMEA, APAC and Americas regions. So if you’re [with]
a service provider organization, a university or small[er] organization, some
of the recommendations I lay out might not apply to you. This focus (or
restriction thereof) is for the simple reason of ignorance. Given I haven’t been
involved in many address planning efforts in such organizations I don’t feel
qualified to advance opinions on their settings.
Such was the title of a talk I gave yesterday at
ACSAC 29. It was an updated and shortened version of a
similar talk I had given at the Troopers IPv6
Security Summit (btw:
this
is the preliminary agenda of the 2014 event).
Having just finished the second
“Advanced Attack Techniques against IPv6 Networks” workshop (some
of the course material can be found
here),
organised and hosted by ERNW and their partner
HM Training Solutions, I would like to
take this opportunity to release publicly one of my scripting tools, an IPv6
scanner. This tool is based on Scapy (so you have to install Scapy and its
prerequisites before using it). It should not be considered as a replacement or
a competitor of nmap against IPv6 or of the scanners incorporated into the great
IPv6 toolkits already released by Marc Heuse
and Fernando Gont,
but, instead, as a tool released mainly for educational purposes. Specifically,
this scanner, apart from supporting some of the most well known port scanning
techniques, from ping scanning to SYN, RESET, ACK, XMAS, etc., etc., TCP or UDP
scanning, it also combines, by using the suitable switches, some IDS/IPS evasion
techniques. As I have found out up to now, at least two of them, if used
“properly”, can be effective against a very popular IDS/IPS software used by
many “Fortune 100” companies out there. This means that you can launch actually
any type of the supported network-scanning techniques while flying under the
radar of this specific IDS software (and perhaps some other too, who knows…).
But first of all, as always please check the corresponding README file.
I recently had a discussion with some practitioners about requirements to IP
Address Management (IPAM) solutions which are specific for IPv6 networks. We
came up with the following:
Mandatory: Track all dynamic IPv6 assignments (SLAAC + PrivExtensions, DHCP
etc.), by polling neighbor caches from network devices. Support SNMPv3 for this
task.
Optional (read: nice-to-have): support other methods than SNMP to gather this
info (e.g. SSH-ing into devices and execution of appropriate “show” commands).
That meeting was actually a
great event. Once more, big thanks! to Fernando for organizing it and to
EANTC for providing the logistics.
A couple of unordered notes to follow:
a) The slides of our contribution can be found
here.
Again, pls note that this is work in progress and we’re happy to receive any
kind of feedback.
[given Fernando explicitly mentioned Troopers, we’ve allowed ourselves to put
some reference to it into this version of the slide deck…]
Next to IETF 87 going on in Berlin
in a few days there will be an
informal meeting of the “IPv6 Hackers”
on Tuesday. We really look forward to personally meet a number of people who we
(so far) only know from the associated
mailing list or
similar machine-enhanced exchange. We hope to contribute as well. Based on the
stuff of
this workshop from
the
IPv6 Security Summit
at Troopers13 we might give a short project
presentation along the lines of “Some Notes on Testing the Real-World IPv6
Capabilities of Commercial Security Products”, providing an overview of some
testing done on commercial gear, together with a discussion of testing
approaches, tools and key aspects.
After his great presentations on
IPv6 Extensions Headers
and
security problems related to fragmentation
we had invited Antonios Atlasis to Heidelberg to give
this workshop
at ERNW. It was a great experience with many fruitful discussions between the
participants (mostly security practitioners from very large organizations
planning to have their Internet edge IPv6 enabled within the next 6-12 months)
and him/us. Antonios thankfully decided to make his
slides
and
scripts
available for those interested in further research on the topics (it should be
noted that the scripts have not been tested thoroughly and he’s happy to receive
feedback of any kind at antoniosDOTatlasisDOTgmailDOTcom). Today Marc (Heuse)
gives
his workshop
on pentesting in the IPv6 age. Hopefully such events help to move things into
the right direction in the IPv6 security space…
Recently Jozef Pivarník and Matěj Grégr published
an
excellent write-up
on RA Guard & evasion techniques. Amongst others they tested the
“undetermined-transport” ACL we described
here
and
here.
As it turns out the “workaround” for implementing undetermined-transport on
platforms seemingly not supporting it, causes some bad collateral damage: the
respective port does not forward any IPv6 packets any more (this was brought
to my attention by Roberto Taccon). We had done some tests after applying it (by
means of the “workaround”) but we had just looked at fragmented RA packets
(which did not get through => test succeeded). So, frankly: the
undetermined-transport trick does not make sense at all on the “unsupported
platforms”…
Due to “popular demand” and given Marc couldn’t join us
at the
IPv6 Security Summit (as
flights into FRA were canceled that day due to snow) we decided to invite him
and
Antonios Atlasis
another time, to present their knowledge, skills & voodoo in two workshops held
in Heidelberg, in late June. More details can be found
here.
See you all potentially at the Heise IPv6 Kongress, take care
on the [ipv6-ops] mailing
list currently there’s some discussion about RA guard support on switches from
different vendors.
Stefan, one of our students (btw: working on a topic similar to this
session),
quickly put together a preliminary list, based on publicly available information
(read: the WWW ;-)). Some of you may find this useful; it can be found
here. Furthermore
on the list
this link
was mentioned which seems to provide some info as well (albeit potentially not
very up-to-date).