Remote Access Policies

   

Remote access policy differs from site-to-site IPsec policy configuration. It is used to specify policy for Road Warriors (Chapter 10) who typically obtain dynamic IP addresses from their hotel, conference, or from an Internet kiosk. Therefore at the time a VPN gateway is configured the IP addresses of Road Warriors cannot be known. This means that the remote portion of the selector must be a wildcard (we will represent this wildcard address as 0.0.0.0) and the address in the via specification for the gateway's policy will also quite often be the wildcard. In addition, when using IKE's Main Mode for Phase 1 it is not possible to use pre-shared key authentication when the remote peer's IP address is not known a priori. This is due to a peculiarity in the IKE protocol the pre-shared key must be based on the IP address since an encryption key to protect the peer's identity must be computed, in part, using the pre-shared key prior to knowing that identity! Since we're sticking with Main Mode, all remote access policies will therefore use rsa-sig as the authentication method.

Because the IP address of a remote access peer is not significant, a gateway will require another way of identifying to whom (in the via portion of our grammar) and how it will speak IPSec. If all remote access users anyone who can be authenticated have the same policy the identifier can be a wildcarded IP address. To constrain access to certain authenticated users, or to provide different groups of Road Warriors with different access, a user's fully qualified domain name (a user's email address) is used.

Consider the following remote access gateway policy to protect traffic to the 165.248/16 network, from any user who can be authenticated, using ESP with HMAC-MD5 and 3DES for IPsec policy and CAST, SHA, and the 1536bit Diffie-Hellman group for IKE policy. Our simple policy language would describe this as:

protect 165.248/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-MD5 3DES tunnel
establish CAST SHA modp-1536 rsa-sig

Note the wildcard address in the via specification. This signifies that this policy is for any user. This rule can be further constrained by indicating a user's fully qualified domain name (user-fqdn) with the via specification. The policy could be further constrained to only apply to people who can be authenticated from the eng.foo.com domain with the following rule:

protect 165.248/16 <-- --> 0.0.0.0
via *@eng.foo.com
using ESP HMAC-MD5 3DES tunnel
establish CAST SHA modp-1536 rsa-sig

The indication of a user's identity (whether she is alice@eng.foo.com or not) is typically indicated in the user's certificate.

Assuming that the gateway with the above policy is accessible via the Internet with the IP address 172.24.46.83, each Road Warrior that needed to remotely access the 165.248/16 network would need the following policy prior to hitting the road:

protect 0.0.0.0 <-- --> 165.248/16
via 172.24.46.83
using ESP HMAC-MD5 3DES tunnel
establish CAST SHA modp-1536 rsa-sig

Remote access selectors with wildcard addresses are not stored in the SPD to be inspected during IP processing like selectors for site-to-site policy. After all, you would not want to attempt to protect all traffic to an unspecified peer! Remote access selectors are merely retained as policy statements. These policy statements are checked during a Quick Mode IKE exchange to determine whether the identity of the peer (authenticated during a phase one exchange) is allowed to access the protected network indicated. If so, a real, dynamic, selector is created and installed in the SPD. The remote access selector is used as a template to create the dynamic selector and the wildcard information is filled in with the peer's actual address. This dynamic and temporary selector is deleted from the SPD when the IPsec SAs it points to are deleted.

For brevity's sake we will not concern ourselves with establishing a certification authority to handle the public key infrastructure to enable signature-based authentication. We will only assume that a user's identity, which can be applied to a user-fqdn regular expression, can be obtained from the user's certificate either in the Distinguished Name or in one of the extensions in that public key infrastructure.

Firewall and VPN Gateway Interaction

An IPsec compliant device is required to perform rudimentary firewalling functionality. This consists of checking a selector during IPSec input processing to see whether the packet should be permitted or denied, or whether it should have IPSec protection in the form of AH or ESP. This can be used to allow or prohibit access to individual hosts, entire networks, or even to specific forms of traffic. If this type of filtering is all that's needed a separate firewall would be extraneous.

In most cases, though, a firewall can be used to provide further protection such as stateful packet filtering, and protection against well-known attacks like fragmentation overflow attacks and TCP SYN denial of service attacks. For packets that would be passed by IPsec (via a permit selector) it would be nice to have some assurance on the benevolence of these packets before they reach the network. Because of this, firewalls and VPN gateways are often deployed together.

When a firewall and VPN gateway co-exist at a network egress point there are three different ways in which they can interact: in parallel, firewall in front, or VPN gateway in front (Figure 11.1). When a VPN gateway and firewall are co-resident on the same box the distinct functionality still lies in one of these combinations, usually "VPN gateway in front".

Figure 11.1. VPN and Firewall Interaction.

graphics/11fig01.gif

When the two devices sit in parallel they both represent valid points of egress from the protected network and ingress to the protected network. In this configuration the network connection to the cloud must be configured to route IKE (UDP port 500) and IPsec traffic (protocols 50 and 51) to the VPN gateway and all other traffic to the firewall. Routing inside the protected network is more complicated though. In the protected network the VPN gateway must be a preferred route for traffic which requires IPsec protection and the firewall must be the preferred route for everything else. If both devices speak a routing protocol they can be easily configured to advertise their preferred routes and dynamically establish the necessary routing state in the protected network. If either one does not then routes must be configured manually. Since these routes have critical security implications great care must be used when configuring them. Whether the devices speak a routing protocol or not, there is additional and critically significant (from a security standpoint) configuration necessary. As the protected network grows or changes, extreme care must be taken to ensure that proper routing of traffic is maintained. For this reason a parallel configuration of VPN gateway and firewall is seldom used.

Another configuration is where the two devices are connected in serial with the firewall connected to the protected network and the VPN gateway connected to network cloud. The VPN gateway has policy to protect certain traffic and permit everything else. This obviates the need for specific routing configuration. It also is an easy way to deploy IPsec without having to reconfigure your firewall something firewall administrators are loath to do. The firewall in this configuration inspects all traffic, even that traffic that was IPsec protected. Naively that may be viewed as a positive but what this means is that there is a point on the network namely the network between the VPN gateway and the firewall where critically important packets are left unprotected.

The final option is where the two devices sit in serial with the VPN gateway connected to the protected network and the firewall connected to the network cloud. In this case the firewall is configured to allow IKE (UDP port 500) and IPsec (protocols 50 and 51) to the VPN gateway and only the VPN gateway. The VPN gateway is configured to protect certain traffic and permit the firewall to handle everything else. The drawback of this configuration is that the firewall now cannot inspect the IPsec protected traffic if it has been encrypted and unless the firewall is intelligent enough to recognize AH it will not know how to inspect any IPsec protected traffic. This is not so serious though when one considers that IPSec is already providing a cryptographic form of protection to these packets which is stronger than anything a firewall can do.

There is no one single best way to have a VPN gateway and firewall interact. Each one has its benefits and drawbacks. Depending on the security policy and paranoia of the network administrator one may be better than the other. Each deployment scenario will discuss the trust relationship and recommend a relationship between a firewall and the VPN gateway. In no way is this a hard-and-fast rule. Your mileage may vary.

A Few Words About Addressing

To avoid using IP addresses that have been assigned to a real company, all addresses used in this chapter will be from the private and globally non-routable address space set aside by IANA, the Internet Assigned Numbers Authority. When a gateway is connected to a cloud it is assumed that the IP address that connects it to the cloud is routable in the cloud. Addresses behind the gateway may be private and are not assumed to be routable in the cloud.

Whether addresses behind gateways are routable or not there is no network address translation (NAT) being performed in any of these deployment scenarios. Since tunnel mode encapsulates packets from one protected network to another, these protected networks can use addresses that are not routable in the cloud that connects them. The only requirement is that their own connection to the cloud is routable in the cloud.


   
Top


IPSec(c) The New Security Standard for the Internet, Intranets, and Virtual Private Networks
IPSec (2nd Edition)
ISBN: 013046189X
EAN: 2147483647
Year: 2004
Pages: 76

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net