IPv6 « Page 4 « b20c:c011:5:b109::/64

Category Archives: IPv6

IPv6 Testing with Veripy

Posted on December 5, 2012 by cbroccoli

Most people agree that an important component of any IPv6 rollout program is the assessment of current systems IPv6 capabilities. This will determine the readiness of an enterprises infrastructure to support an IPv6 rollout. Within the scope of an overall IPv6 program, the assessment phase should take place between the Education and Building Awareness phase and the start of any Pilot Projects. A prerequisite for the assessment, however, is the installation of a lab environment, since the assessment cannot only cover the vendor’s stated readiness but also live, automated tests against devices to verify that the vendor’s statements are indeed true. Since automated tests require IPv6 to be installed on a system, and the impact of the tests cannot be known in advance (for example crashing the system under test), using a lab would be a pragmatic approach.

Of course there are a number of organizations who perform these tests already and who publish the results, so not all systems within a certain environment need to be directly tested, just those which may be unique to a certain IT environment or those which have not been previously tested. The most well known list of results is the one found under the IPv6 Forum’s Ready Logo Program. NIST has also developed test profiles specifically to support the US Government’s OMB mandate. The following two labs provide lists of equipment tested against these profiles.

Loosely based on the NIST profiles, RIPE has also developed a list of requirements (specified in RIPE-554) for ICT equipment which may not be taking part in the IPv6 Logo Program but may also need to be considered for IPv6 support. The RIPE requirements are meant to be more general than the NIST requirements and can be used by all enterprises for determining the level of compliance of any ICT equipment. RIPE-554 tests devices against the MUST and SHOULD requirements in the following set of IPv6 RFCs.

RFC 1981 – Path MTU Discovery for IPv6
RFC 2460 – IPv6 Basic Specification
RFC 2473 – Generic Packet Tunnelling and IPv6
RFC 2711 – IPv6 Router Alert Option
RFC 3315 – DHCPv6
RFC 3484 – Default Address Selection
RFC 3633 – DHCPv6 Prefix Delegation
RFC 3736 – Stateless DHCPv6
RFC 3971 – SEcure Neighbor Discovery (SEND)
RFC 3972 – Cryptographically Generated Addresses (CGA)
RFC 4213 – Basic Transition Mechanisms for IPv6 Hosts and Routers
RFC 4443 – ICMPv6
RFC 4861 – Neighbor Discovery
RFC 4862 – StateLess Address Auto-Configuration (SLACC)
RFC 5095 – Deprecation of Type 0 Routing Headers in IPv6

For more information, visit the RIPE-554 website.

With this in mind, I set out to see what tools are available to automate this testing process. The first tool I came across was veripy. veripy directly tests devices based on RIPE-554 requirements so I thought it would be a good tool to start with. As usual, I learned more in performing these tests than information about IPv6 testing. In the posts that follow, I will walk through the lab setup, configuring and installing veripy, and finally running some tests and their results.

RSA 2012 Day 4: IPv6 Vulnerability Management and BYOD

Posted on March 2, 2012 by cbroccoli

No Comments

Two good sessions today, one on the state of vulnerability management in IPv6 and the second on the security issues with BYOD.

The vulnerability management session was interesting in that while Microsoft, all Linux variants, Cisco, HP, Juniper, Check Point and other OS and network device vendors have been implementing IPv6 capabilities into their products, the vulnerability management vendors have been sleeping. They are just coming to the realization that customers would like to be able to perform vulnerability tests for IPv6 enabled hosts on their networks. I mentioned in my post yesterday that the primary issue with performing vulnerability scans on IPv6 is the scarcity of the addresses in an IPv6 address space. It is simply not possible to scan all of the addresses in a single IPv6 subnet to find hosts and to then probe for vulnerabilities in a reasonable amount of time. The vendors are working on models to do this; however, no final “best practice” solution is available yet. Some suggestions which were presented are to scan active IPv4 addresses to find the hosts and then check if they are running IPv6, to perform SNMP walks on the routers or switches to determine which hosts are running IPv6, review the CMDB for known hosts or review log files on network and other devices.

In the BYOD session, the primary discussion revolved around identifying the threats to mobile devices in general, but only two possible models for supporting BYOD emerged. The primary threats to mobile devices as seen by the panel are:

Bridging from a mobile device into the enterprise network
ActiveSync vulnerabilities
Rouge base stations which can eavesdrop on calls
Lack of granular controls for many of the mobile OS’
Poor password usage since users find it difficult to type in complex strong password

The two models which were discussed for supporting a BYOD model are to either require the user to accept corporate policy controls (e.g. encryption, virus scanner, etc.) on their personal device by installing an enterprise MDM solution or to implement local virtual containers on the devices. The container solution would solve the problem that if a user leaves the company, only the corporate container can be wiped and the personal container can remain in place.

In both situations, a security policy should define what applications will be made available to users who bring their own devices. This policy should be based on the criticality and security requirements of the applications as well as the usability of the applications. For example, does it make sense to allow access to spreadsheets from iPhones when they really cannot read or manipulate them in any practical manner?

RSA 2012 Day 3: Securing IPv6 and Moving to the Cloud

Posted on March 1, 2012 by cbroccoli

No Comments

The first session today covered the basics of security in IPv6. IPv6 contains some features which provide it with some additional security. Some are not actually features designed into the protocol but just exist because of the nature of the IPv6 address space, for example brute force scanning of IP addresses will no longer be possible with IPv6 just because of the sheer size of the address space you will need to scan. Of course on the down side, this feature makes vulnerability scanning also impossible if it is based on scanning IP addresses. The same is true when using ULA addresses for internal private addressing (like the 10.0.0.0 in IPv4). Since the number of ULA networks is so great, each company can pick their own and there will be virtually no chance that there will be an overlap with other companies. Worms will no longer be able to spread just by counting up IP 10.0.0.0 addresses and infecting the next active device. Finally designed in features, such as IPSec or secure neighbor discovery do secure the protocol, howver, since IPSec is no easier to manage in IPv6 than it is in IPv4, it does not provide any additional security over using IPSec in IPv4.

Administrators should also actively implement certain controls to secure IPv6. Controlling the boundaries of where headers can be distributed, controlling rogue router advertisements through using IPS and filtering at the layer 2 switches, and blocking tunnels (6to4, 4to6, etc.) from any but approved tunnel endpoints will help to secure an IPv6 based network.

The final recommendation is to develop an IPv6 security policy which parallels an IPv4 policy. Everyplace where you have a policy which references IPv4 should also have a statement about IPv6 plus there should be some IPv6 specific statements to cover the IPv6 specific features.

In the Cloud session, the CTO from NASA’s Jet Propulsion Labs discussed how they use public and private clouds within their organization. They have developed a very interesting model of using both public and private clouds depending on what the use case is for the data and applications being implemented. The model allows the users to define their requirements for their application in an on-line tool and they will be given options showing which cloud based services are allowed to be used based on security level, performance, availability, cost and other factors.