Multiple Company Extranet Example

   

Now let's consider a different deployment case. That of an Extranet that is built to enable multiple companies let's say four to retain consistency with our example above to collaborate and/or cooperate in some new business development.

All companies in this case are independent companies. They all have their own access to the Internet and all maintain their own independent security policy. In fact, one of these companies could be NetWidgit from the Four Office Company example above with a fully meshed or hub-and-spoke VPN tying all its offices together in addition to the collaborative Extranet built between it and its partners. IPsec is powerful and flexible enough to allow a company to build a corporate and a collaborative Extranet together.

The trust relationship between these companies will be one of mutual suspicion. They may be partnering together for one aspect of their business but they may compete in another. For this reason it may not be acceptable to have the same firewall/VPN gateway relationship we had above. IPSec input processing requires checking a packet against a selector after the packet has been processed. This ensures that merely establishing a security association will not open up a network to all traffic that a peer wants to put in the tunnel. For example, if a security association was created to protect TCP traffic to a particular host then only TCP traffic to that particular host will be allowed, all other traffic sent under that security association, even if it was properly authenticated and decrypted, will be dropped. In some cases though this may not be enough. The suspicious nature of this Extranet relationship may force companies to place the firewall between the VPN gateway and the protected network. Such an arrangement will provide additional firewalling protection to packets which had been IPsec protected. Let's assume this is the case for this example.

Now you may be saying to yourself, if the firewall is protecting the network, it is effectively treating traffic from the VPN gateway as if it was from the Internet, so why not just get rid of the VPN gateway? Firewalls, even the smart kind, are kind of dumb. They blindly enforce rules on packets but they assume that the packet has not been forged, replayed, inspected, or modified en route by a bad guy. An Extranet protected only by a firewall would not only lose the ability to remain confidential, it would also open the Extranet up to attack. The IPSec-enabled VPN gateway will ensure that packets are not modified or replayed and also establish a cryptographic binding to the source to ensure they are not forged.

Single Site Hosts Extranet

In this situation the physical equipment that supports the collaborative work of the Extranet is hosted at a single site. This site could be a member of the collaborative group or it could be third party hosting. Let's assume it is the former because it makes the security implications more interesting.

The company hosting the Extranet is concerned about restricting the Extranet partners to the Extranet only. The actual machines a partner may use to access the Extranet (from where the partner is coming) are not necessarily important, as long as access (to where the partner is going) is restricted. This can be accomplished by opening up the Extranet to the partners' entire networks. Another way could be to establish a trusted Certification Authority to issue certificates only to trusted Extranet partners and then having remote access policy to restrict Extranet access. Either way accomplishes the same thing from the point of view of the hosting company, it doesn't matter where they're coming from, it matters where they're going!

The security of the equipment that is not part of the multi-party Extranet must also be maintained since these parties are still mutually suspicious. The company hosting this Extranet does not want to give access to its other resources to its Extranet partners. This can be accomplished ensuring that traffic to and from the Extranet is not routed through the corporate network or by using IPsec policy and firewalls to enforce corporate security and ensure that no Extranet partners sneak off to other confidential parts of the company that is hosting the Extranet. Let's assume the latter, again because it makes the security implications more interesting. The Extranet equipment will be on a subnet the 10.1.89.128/23 network of hosting party's secure network.

There are also security implications among the other parties of the Extranet that are not hosting the equipment. They want to allow their company to access the equipment used for collaboration but not the other way around. That is, they don't want to give access to their resources to Extranet partners, all they want to do is ensure their own access to the Extranet. This is best accomplished with a stateful inspection firewall which will allow traffic in only if it is part of a stream that initiated the connection out. An especially paranoid partner may wish to be even more protective though, and allow Extranet access only from a few select machines in his network.

Note that these threats are not symmetric. The hosting company wants to allow anyone from a partner's network into the Extranet and only the Extranet. The non-hosting partners want access to the Extranet but still want to prohibit any access to their networks.

Similar to our previous example in which there was a central office and several remote branch offices, here there is a hosting company and several collaborative partners that comprise the Extranet, Figure 11.5. Note that the network being used for the collaborative Extranet is on the company's protected network. In addition, note that Company D (from the 10.4/16 network) wishes to restrict Extranet access from one small subnet on its network (the 10.4.24.113/28 network). This will provide it with added security assurance in addition to its IPSec and firewall policy at the cost of requiring workers who wish to take part in the collaborative work to physically move to the 10.4.24.113/28 subnet.

Figure 11.5. Single Site Extranet.

graphics/11fig05.gif

First let's consider the situation where there is no Extranet Certification Authority and no remote access policies. The hosting company wants to allow traffic that is only for machines used in the collaborative Extranet and exclude everything else. IPsec policy to express this is:

protect 10.1.89.128/23 <-- --> 10.2/16
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/16
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 firewall would need to be able to restrict access to non-Extranet resources in the hosting company's network, in addition to whatever policy it already has. In addition, the network connecting the VPN gateway and the firewall is now unprotected and other techniques physical security perhaps will have to be employed to ensure there is no breach of security there.

Policy for the Extranet partners will be similar, each one protecting traffic from their network to the Extranet network inside the host's network going through the host's gateway. Policy for Company B to the Extranet:

protect 10.2/16 <-- --> 10.1.89.128/23
via 172.24.16.1
using ESP HMAC-MD5 3DES tunnel
establish AES SHA modp-1536 pre-shared

policy for Company C to the Extranet:

protect 10.3/16 <-- --> 10.1.89.128/23
via 172.24.16.1
using ESP HMAC-MD5 3DES tunnel
establish AES SHA modp-1536 pre-shared

policy for Company D's small subnet to the Extranet:

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

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

permit 0.0.0.0 <-- --> 0.0.0.0

The firewall between each partner's VPN gateway and his protected network must then have stateful packet filtering rules to only allow connections between 10.1.89.128/23 and the local network if they have been initiated from the local network. This will prevent a partner from accessing the Extranet machines and then reversing course and going out of the Extranet and into another partner's protected network.

If there is a Certification Authority, IPsec configuration is easier (but that is more than exceeded by the work required to get a Certification Authority up and running). The CA could even be one already established and in use at the host company. All that is required is that it issue certificates to partners with some identifying information. Let's assume that is the user's email address @ extranet.foo.com.

Remote access policy to limit access only to Extranet partners could be added to the above configuration. This would allow road warriors of the various Extranet partners to acquire access to the Extranet while on the road.

The entire configuration above could even be scrapped in place of remote access rules. Site-to-site rules are not strictly necessary. In this case the VPN gateway of the company hosting the Extranet would then need the following IPSec policy:

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

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

permit 0.0.0.0 <-- --> 0.0.0.0

Remote access clients of the Extranet partners would then need:

protect 0.0.0.0 <-- --> 10.1.89.128/23
via 172.24.16.1
using ESP HMAC-MD5 3DES tunnel
establish AES SHA modp-1536 rsa-sig

This simplifies configuration quite a bit. The only caveat is that you must ensure that the Certification Authority will only issue certificates with the extranet.foo.com fully-qualified domain name to valid Extranet partners. Control over access to the Extranet is now in the hands of the Certification Authority.

Each Site Hosts Extranet

When each site hosts some part of the Extranet computers, printers, audio-visual equipment, etc. the security needs of each partner now mirror that of Company A when it hosted the entire Extranet. Each partner now must allow access in to some part of its network and ensure that no one sneeks off.

First, let's consider the case where there is no certification authority. In this situation it is extremely difficult to set-up policies which are not strictly based on IP source and destination addresses. Partners used to have asymmetric policies which allowed access from anywhere in their network but prohibited access to their network. Now they have to allow their partners in. Each partner will have to establish which part of its network will be part of the Extranet and when employees wish to collaborate in the Extranet they will have to physically move onto the local subnetwork which houses the local part of the Extranet (Figure 11.6). This makes for a simple policy configuration each site has policy to protect Extranet traffic to the other three sites. In fact, this will look very much like the fully-meshed example above. Company A protects Extranet traffic to Companies B, C, and D:

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

Figure 11.6. Multi-Site Extranet.

graphics/11fig06.gif

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

permit 0.0.0.0 <-- --> 0.0.0.0

Company B protects Extranet traffic to Companies, A, C, and D.

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

protect 10.2.42.1/24 <-- --> 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.2.42.1/24 <-- --> 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 configuration for Company C and Company D would be straightforward then where policy protects traffic from the local portion of the Extranet to the other three partner's remote portions of the Extranet.

The presence of an Extranet Certification Authority makes things a bit different. Wildcard policy statements are realistic now and it is no longer necessary to force workers onto a certain subnet just to take part in the collaborative Extranet. But the benefit of allowing local employees to not have to physically move to work in the Extranet comes with a cost: it is necessary to treat local employees the same way that a partner's employees are treated. An employee of Company C who is not physically on the local portion of the Extranet will have to authenticate herself to Company C's VPN gateway in the same way an employee of Company D must.

From the point of view of each company's VPN gateway the configuration is now much simpler. There need only be a single wildcarded policy. Company A will have:

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

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

permit 0.0.0.0 <-- --> 0.0.0.0

Company B will have:

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

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

permit 0.0.0.0 <-- --> 0.0.0.0

Companies C and D will similarly have a single wildcarded statement protecting its portion of the Extranet and an explicit permit statement.

The configuration of each user who wishes to have access to the Extranet will be a bit more complicated though due to the fact that the Extranet is disparate. Each company's employee who wishes to do collaborative Extranet work will need the following:

protect 0.0.0.0 <-- --> 10.1.89.128/23
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig

protect 0.0.0.0 <-- --> 10.2.42.1/24
via 172.24.16.2
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig

protect 0.0.0.0 <-- --> 10.3.11.89/28
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig

protect 0.0.0.0 <-- --> 10.4.24.113/28
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig

Again, notice the similarity to the remote access case of the fully-meshed corporate VPN above. Since all employees are treated equally, an employee of Company D wishing to access the Company D Extranet resources would be treated in the same fashion as an employee of Company A wishing to access the Company D Extranet resources.


   
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