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).