Outsourcing Networks

   

For organizations that want to outsource the deployment of their networks, it is possible for ISPs (Internet Service Providers) to design, deploy and maintain the network. An organization may decide to outsource the deployment of its network because of the following issues:

  • Reduce management overhead

  • Better performance as the ISP can potentially have faster machines particularly in CO based solution

The ISP has two design choices: either deploy the gateways that are implementing IPSec in the edge of the organization or deploy the gateways that are implementing IPsec at the edge of the ISP network. The former option is called CE (Customer Edge) and the latter is called Provider Edge (PE) based solution.

The biggest issue with this solution is "trust". The following are some questions to be addressed:

  • Who controls the policy for security?

  • The mechanism to create secure Intranets and Extranets

  • How often one gets to update policies or create Intranets and Extranets

  • The time it takes to service a request

  • Most importantly, guaranteeing security of packets, e.g. no one is snooping on the packets, or modifying data or injecting traffic

In this section, we will examine the issues, limitations and advantages of outsourcing networks. In addition, we will also consider cases and the policy required to design and implement outsourced Intranets and Extranets.

PE versus CE based solution

As mentioned in previous sections, there are two methods in which an ISP can design an outsourced secure network. The devices (firewalls and gateways) that implement security can be located either at the edge of the ISP's network (PE based) or at the customer edge (CE based). These deployment scenarios are shown in Figure 11.7.

Figure 11.7. CE- and PE-Based Deployment Scenarios.

graphics/11fig07.gif

Both these solutions pose different challenges. In the CE based solution, the ISP is probably carrying only the organization's traffic on the gateway that is sitting at the edge of the organization. Hence, they can give more control to the organization to manage this gateway. However, there is a price associated with this. It requires someone in the organization to be able to configure policies to build secure Intranets and Extranets. However, this undercuts one of the goals of going to an outsourced network in the first place. There may be issues with liabilities as the ISP may have to guarantee a certain level of security.

PE-based solutions has greater emphasis on trust as the ISP may be carrying traffic from multiple companies on the gateway. If the security on the gateway is compromised it has wide ranging implications as it may affect multiple organizations. This may force the ISP to limit the exposure it gives to organizations on setting or changing their policies. For example, the policy change capability may just be limited to changing the algorithms or restrict access to remote users but not allow creation of Intranets or Extranets.

There is no one rule that fits all for the issues discussed above. It is driven by contractual obligations, the requirements imposed by the organization, and the limitations of the ISP.

Deployment Scenarios

In this section, we will consider the three different scenarios

  • Building Intranets

  • Building Extranets

  • Build third party based Extranet solution

Intranets

In previous sections, we considered the deployment scenario for building Intranets. The policy configuration for an outsourced Intranet is identical to those discussed in non-outsourced solutions. The only difference is in the case of a PE-based solution. In this case, the policy is configured on the ISP's edge gateway instead of the gateway located in the customer's network.

The only other deployment issue is in the case of global organization where the geographically distributed locations may have different ISPs. In this scenario, the ISPs need to coordinate among themselves to set up the policies, which is an involved process.

Extranets

Deploying an outsourced Extranet where the machines participating in the Extranets are located in the customer's network is simple if the following conditions are met:

  • All the machines in each organization participating in the Extranet are in physically separate network.

  • The organization has a direct connectivity to the ISP's network and there are no other connections to the Internet, e.g., via a dialup modem.

  • Once on a machine that is part of an Extranet, employees cannot initiate connections to other machines in the organization that do not belong to the Extranet.

The Extranets can be implemented in both PE- and CE-based solutions. The main difference between the two solutions is the placement of firewall. In case of PE-based solution, the firewall is placed in the front on the gateway implementing security in the ISP network as shown in Figure 11.8. This solution also requires that all the traffic originating from within the Extranet network is always forwarded to the PE firewall for the firewall to perform stateful filtering. This enables denying access to the machines that do not belong to the Extranet from within the Extranet.

Figure 11.8. PE-Based Security Solution.

graphics/11fig08.gif

In case of a CE-based solution, the firewall is placed in front of the gateway in the customer's environment as shown in Figure 11.9. This firewall performs stateful filtering of packets to deny access to the machines not part of the Extranet.

Figure 11.9. CE-Based Security Solution.

graphics/11fig09.gif

Continuing with our four Extranet partner example, let us consider the case where each partner has put the machines participating in the Extranet in a separate network as shown in Figure 11.10.

Figure 11.10. Outsourced Multi-Site Extranet Solution.

graphics/11fig10.gif

The policy on the gateway IRA is:

protect 10.1.89.128/23 <-- --> 10.2.42.1/24
via 172.24.16.2
using ESP HMAC-MD5 3DES tunnel
establish AES SHA modp-1536 pre-shared

protect 10.1.89.128/23 <-- --> 10.3.11.89/28
via 172.24.16.3
using ESP HMAC-MD5 3DES tunnel
establish AES SHA modp-1536 pre-shared

protect 10.1.89.128/23 <-- --> 10.4.24.113/28
via 172.24.16.4
using ESP HMAC-MD5 3DES tunnel
establish AES SHA modp-1536 pre-shared

and an explicit permit rule to allow other traffic to be protected by a firewall:

permit 0.0.0.0 <-- --> 0.0.0.0

The policies for IRB, IRC, and IRD mirror that of IRA.

If CA-based policy is used, then it is possible to allow access from the Extranet into the corporate network as it is possible to identify the person trying to access the corporate network from the Extranet network. In this case, the policy to access the corporate network is based on certificates.

The policy on IRA is as follows:

protect 10.1.89.128/23 <-- --> 0.0.0.0
via *@extranet.foo.com
using ESP HMAC-MD5 3DES tunnel
establish AES SHA modp-1536 rsa-sig

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

The first policy is to access the Extranet network and the second policy is to access the corporate network. However, the configuration for each Road Warrior gets more complicated as they have to have a policy to access the Extranet hosted in each company.

Third Party Extranet

Many of the complications seen in the previous section can be avoided by a third party Extranet solution. This is because the organizations do not have to worry about someone accessing the corporate network from the Extranet network as the Extranets will be in physically separate network. The policy configuration reduces considerably compared with multiple companies hosting the Extranets. The policy does not have to change every time a new company becomes an Extranet partner.

The main issue with this is that data storage and the security is outsourced. This again comes back to the trust issue. Many companies already offer outsourced data storage solutions. Third party Extranets can be considered as the next step. However, certain guidelines have to be followed in deploying the Extranets. The machines in the hosting company's network should participate in only one Extranet or else the data may be compromised.

Let us go back to the four company Extranet example except in this case, the Extranet is hosted by a third party. The deployment of this Extranet is shown in Figure 11.11.

Figure 11.11. Third-Party Extranet

graphics/11fig11.gif

The following rule still applies: The access to the Extranet is asymmetric, i.e., valid machines or users from the participating companies can access the Extranet. However, users cannot access any of the systems by originating traffic in the Extranet. Hence, the firewall that connects to the Extranet cloud should perform stateful filtering of packets.

The policy configuration on the gateway connected to the Extranet is as follows:

protect 10.1/16 <-- --> 10.2/16
via 172.24.16.2
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared

protect 10.1/16 <-- --> 10.3/16
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared

protect 10.1/16 <-- --> 10.4/16
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-share

protect 10.1/16 <-- --> 10.5/16
via 172.24.16.5
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-share

and a policy for the remote access users wanting to access the Extranet:

protect 10.1/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig

and an explicit rule to drop all other traffic:

drop 0.0.0.0 <-- --> 0.0.0.0

The policy configuration on Company A to access the Extranet is:

protect 10.2/16 <-- --> 10.1/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared

Companies B, C, and D will have similar policies, except that the source subnets will be their subnets.

The main advantages of the third party Extranets are:

  • It is more scalable compared to each site hosting the Extranet. The policy of each user accessing the Extranet does not need any modifications when another company joins the Extranet partnership.

  • In terms of scalability, this solution has the same advantages as that of a single company hosting the Extranet. However, the outsourced solution has the potential to provide better infrastructure than what a company can provide, particularly if the Extranet needs to be built for relatively short period of time. The time for deployment can be considerably reduced this case.

Issues in Outsourced Networks

There are numerous issues that have to be addressed in outsourcing secure networks. Security is a very sensitive issue. The reason one would want to secure a network is to stop others from snooping or modifying the packets. The fact that there is a dependence on a third party to provide the security may make some people nervous. However, this should not be a deterring factor in outsourcing most of the secure networks. These issues can be resolved by proper contractual obligations between the ISPs and the organization outsourcing the networks and the ISPs taking proper measures to provide the level of security required by the organizations.

Policy

It is evident that policy plays a key role in the deployment of secure networks. If the policy is compromised, then security of the network is compromised. For example, the attacker can just change the policy to use DES instead of 3DES or even worse, do NULL encryption. In this case, even though the packets are being secured, they are being secured with either a less powerful encryption algorithm, or even worse, sent out in clear text.

The issue of how to create the policy and maintain it is key in outsourced secure networks. It is possible that the customers may demand that they have complete control on the policy. However, this has implications to the ISP because they have to:

  • Validate that nothing the customer does violates the contractual obligations.

  • It is possible that the ISPs are servicing multiple clients and the policy is maintained in the same database. In this case, they have to restrict the access the customer has to the policy so that they cannot access the policy that belongs to other customers.

The fact that there are no standards that determine how policy is deployed and stored raises a good question: How should a policy be implemented? On one extreme, the ISP can say that the customer cannot have any access to the database, or on the other extreme they can give full access. There may be intermediate solutions such as the customer having the ability to specify denial of access for a remote access client; this is particularly important when the employee is terminated and they should no longer be accessing the network. The solution that the ISP can provide is dependent on how they have deployed their policy and what capabilities the schema provides.

If the policy uses certificates, there is the whole issue of establishing the Certificate Authority so that the ISP can properly authenticate the users. The two issues that stand out in the management of these certificates is the root certificate the ISPs should use to authenticate who can access the protected networks and how one would revoke the certificates. Both of these are extremely critical issues that should be addressed. Issuing and maintenance of certificates and the Certification Authorities is a whole subject by itself.

Security In ISP Network

The main customer issues the ISP has to address are:

  • Gateway and Firewall Security: The ISPs have to guarantee the security of the devices that perform security and where policy is maintained. They will have to do this by making sure that these systems are physically secure and the access to this system is restricted. If the security of these systems is compromised, then the security of the entire network is compromised.

  • The connection between the customer edge gateway and the ISP edge gateway that is securing all the customers traffic should be a direct link. There should not be any intermediate devices, as the more devices the packet passes through in clear text, the greater the probability of the security being compromised.

  • Packet snooping: The ISPs also have to make sure that they prevent snooping in their network. Their network should be architected to prevent the placement of snooping devices on the link between the customer's edge and the ISP edge. Snooping opens up a whole lot of issues. As these packets are captured before the packets are encrypted, it is possible for the rogue person to capture the contents in clear text or modify clear text, or inject packets in either direction.

Multiple ISP's Issues

In case of global organizations, two or more ISP's may have to collaborate to provide the secured outsourced solutions. Although from the deployment perspective the policies and configuration remain the same, the issue of trust and responsibility becomes tricky. From a customer's perspective, they would like to have one ISP provide the guarantee of securing their network. It is then up to ISP's to define the domain of control and guarantee the security for their clients.


   
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