Section 5.8. Enterprise Security Models for IPv6

5.8. Enterprise Security Models for IPv6

End-to-end transparency and security has been lost in many IPv4 networks due to the need to introduce NAT because of the shortage of IPv4 addresses. IPv6 can restore the transparency. However, some people have become used to seeing NAT and private addressing schemes to provide security in enterprise networks by hiding the network topology from the outside. These people may perceive the IPv6 transparency as a threat to their network and may even plan to deploy IPv6 networks with private local addressing schemes and translators only for this reason.

The goal with IPv6 is to restore end-to-end connectivity by using the abundant address space. To secure an IPv6 network, a security concept has to be created and the security mechanisms have to be implemented. NAT should no longer be used with IPv6. If hiding network topology from the outside is a requirement, other mechanisms should be used, such as private addressing (RFC 3041), unique local addresses (ULAs), or untraceable IPv6 addresses. Find a detailed description and discussion of these options in draft-ietf-v6ops-nap-02.txt, "IPv6 Network Architecture Protection" (NAP).

5.8.1. The New Model

In IPv4 networks, the favored model for security is to have perimeter firewalls and integrate NATs. Applying this same approach in an IPv6 network may be a good starting point, but is limiting in the long term. In IPv6 networks, you should aim to design an improved security model that increases the overall security of the network but also facilitates end-to-end communication. IPv6 provides IPsec capability in each node. Relying on one perimeter firewall can be dangerous. An attacker who manages to get behind the firewall will usually find an open unsecured field. The optimal security concept for IPv6 networks will most likely be "defense in depth," a combination of centralized security policy repositories and distribution mechanisms that, in conjunction with trusted hosts, will allow network managers to place more reliance on security mechanisms at the end points and allow end points to influence the behavior of perimeter firewalls. Perimeter firewalls will be responsible for securing the network from general attacks, and the end node will be responsible for securing itself from node-related attacks. The new security policy model for IPv6/IPsec networks must be an identity-based model in order to separate security policy from network IDs. This is crucial for networks that want to allow for automation, autoconfiguration, and mobility without compromising security. This new distributed security model is emerging, and some of the technologies required are still under development, including protocols to allow end nodes to control and inform firewalls. Initial IPv6 deployments probably make use of similar firewall and intrusion detection techniques as used in today's IPv4 networks (with the exception of NATs, which should not be used at all in IPv6 networks). But the final goal to introduce a new type of distributed security concept should be kept in mind as you go along, and the development of these technologies should be followed closely.

There may be two types of managed security models depending on the size of the network to be secured:

End Node Distributed Firewall Model

A site security manager server authenticates end nodes on a network and then distributes firewall policies to end-node firewalls. This includes firewall configuration, access policies, IPsec keys, virus protection, etc. No site-level access control is required. Once an end node is authenticated and updated with a security policy, it is solely responsible for its own security.

Hybrid Distributed Firewall Model

A site-level security manager server may handle end-node authentication and distribution of firewall policies to both site firewalls and end-node firewalls. Once end nodes are authenticated, they can be granted varying levels of privilege by the security manager. The security manager's set of policies determines who has access to the outside, who has access to each other internally, which types of services and protocols may be run by different nodes, and who gets IPsec keys. The perimeter firewalls do some light access control while distributing the heavy work to the end-node firewalls. Various levels of coordination and control are possible in this model. In a simple version, end-node firewalls may run independently after being given the local firewall rule set by the security management service. In a more tightly managed version for high-security networks, the controller may coordinate between Intrusion Detection Systems (IDS), the site firewall, and end-node firewalls to detect attacks and shut off access to dangerous users inside or outside the corporate network.

One main source of information for the new model is a presentation by David B. Green, given at the North American IPv6 Task Force (NAv6TF) Technologist Seminar in November 2004 at the George Mason University, Washington, D.C. We thank David for the permission to present it in this book.

5.8.2. IPv6 Firewall Filter Rules

When you live in a dual-stack network, you will have two security concepts: one for the IPv4 world and another for the IPv6 world. And the two concepts do not have to match; they have to be designed according to the requirements of each protocol. Your firewalls may support both protocols, having two separate filter sets (one for each protocol), or you may have two boxes, one being the firewall for the IPv4 network and the other being the firewall for your IPv6 network.

Without trying to provide a full-fledged Security and Firewall Guide, here are some ideas for IPv6 security provisions and firewall filters that should be considered:

• Ingress filter at perimeter firewall for internally used addresses.

• Filter unneeded services at the perimeter firewall.

• Deploy host-based firewalls for a defense in depth.

• Critical systems should have static, nonobvious (randomly generated) IPv6 addresses. Consider using static neighbor entries for critical systems (versus letting them participate in ND).

• Hosts for Mobile IPv6 operations should be separate systems (to protect them by separate rules).

• Ensure that end nodes do not forward packets with Routing Extension headers.

• Layer 3 firewalls should never forward link-layer multicast packets.

• Firewalls should support filtering based on Source and Destination address, IPv6 extension headers, and upper-layer protocol information.

• Check your network for external packets that did not enter through your main perimeter firewall as an indication of "backdoor" connections of surreptitious tunneling.

In IPv6 networks, ICMPv6 plays a fundamental role and provides great functionality. Uncontrolled forwarding of ICMP messages also creates security risks. draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt, Best Current Practice for Filtering ICMPv6 Messages in Firewalls, provides recommendations for the configuration of ICMPv6 firewall filtering rules (specifically, allowing the forwarding of messages that are important for the functioning of the network and dropping messages that are potential security risks).

Let's move on from security to Chapter 6, which covers another interesting topicQuality of Service.