Deployment Scenarios (Using IPsec to Secure the Network)

We have seen how IPsec operates in a stack, how a selector database is constructed, how IPsec is applied to packets matching selectors, and how IKE negotiates security associations for use by IPsec. But how is IPsec actually deployed to help protect a network?

Before we dive into various deployment scenarios, though, it will be helpful to define how IPsec is presented to an administrator. One way it can be represented is as a virtual interface. All packets going into and out of this interface have IPsec applied to them. This is a useful representation on a router because routers have the ability to configure virtual interfaces for other encapsulation schemes (for example, GRE). The benefit of this representation is that routing protocols can be run on a interface, just like any other interface. The drawback of this representation is that now routing is playing a role in securing the network.

Another way of representing IPsec is as another step in IP processing. Prior to making a forwarding decision, the policy database is consulted to determine whether a packet should have IPsec applied to it or not. If IPsec is not required for a packet it is merely forwarded as the next step in IP processing. If IPsec is required the packet is encapsulated (the destination address may possibly change) and then it is re-inserted back into IP processing where it may or may not require another IPsec encapsulation (remember the packet onion from chapter 10). This method is simpler to represent IPsec to the administrator and will be used when describing various deployment scenarios here. It should not be difficult to imagine each scenario with a virtual interface representation—it just requires a bit more configuration.

Each configuration scenario is implemented using a policy which will be described using a simple policy language. Implementations of IPsec will probably use a different grammar to specify configuration. Some will be solely graphical, others solely command-line based, and others will be a mix of the two. Regardless of how a specific device is configured, the information that needs to be configured will remain essentially the same and that will allow the simple pseudo-grammar used here to be translated into actual configurations straightforwardly.

To define a policy we must identify what traffic to protect, with whom it should be protected, how it is to be protected, and how we establish an authenticated connection with our remote peer. If we pare down the number of configuration options our policy language can be simpler without any loss of power. We will therefore limit ourselves to three types of ciphers—AES, 3DES, and CAST, two hash algorithms—HMAC-SHA and HMAC-MD5, two Diffie-Hellman groups—the 1024bit and 1536bit MODP groups, two methods of authentication with IKE—pre-shared keys and RSA signatures, and no PFS used in Phase 2 IKE. In addition we'll use IKE's Main Mode for Phase 1. This is mandatory to implement for IPSec compliance and will therefore be present in all IPSec implementations.

The policy language will consist of keywords (in boldface) and their options (in italics). For example, IPsec protect policy is represented as:

• protect selector via peer using ipsec-suite establish ike-suite

which specifies what traffic to protect, to whom, how to protect it, and how to speak IKE. IPsec permit or deny policy is represented as:

• permit selector
• deny selector

which specifies the traffic to permit or deny.

Now let's define the configuration options themselves. What to protect consists of a selector which identifies a flow:

selector: address <-- --> address [ ULP [port]]

The peer is identified by an IP address or fully qualified user name:

peer: address user-fqdn

How the traffic is protected is defined as a "suite" for IPsec:

ipsec-suite: protocol authenticator [cipher] mode

How IKE is spoken is defined as a "suite" for IKE:

Ike-suite: cipher hash group auth-method

Each component of these constructs can then be further defined as:

• Address: W.X.Y.Z or a CIDR-style network specification
• User-fqdn: email-style name (name@company.com)
• Protocol: AH, ESP
• ULP (Upper Layer Protocol): TCP UDP
• Port: a port number for an upper-layer protocol
• Authenticator: HMAC-SHA, HMAC-MD5
• Cipher: 3DES, AES, CAST
• Mode: tunnel, transport
• Hash: SHA, MD5
• Group: modp-1024, modp-1536
• Auth-method: pre-shared, rsa-sig

Let's view a couple of examples of how to use this language:

protect 165.248/16 <-- --> 10.1.1/24
via 172.24.56.1
using ESP HMAC-SHA CAST tunnel
establish AES SHA modp-1536 pre-shared

This describes a policy to protect all traffic between the 165.248/16 network and the 10.1.1/24 network using ESP with HMAC-SHA and CAST in tunnel mode with a peer gateway at gateway 172.24.56.1, and to speak IKE with AES, SHA, pre-shared keys and the Diffie-Hellman group with the 1536 bit prime modulus.

Policy to allow traffic from 165.248.23.8 to 10.1.1.74 and deny everything else would be:

permit 165.248.23.8 <-- --> 10.1.1.74
deny 0.0.0.0 <-- --> 0.0.0.0