What Are the Trade-offs?

A very important part of developing your deployment model is to consider not only the initial deployment, but maintaining the System Policies on all the systems that use Intel® Packet Protect in your network.

Clearly, the simplest model we discussed will be the easiest to deploy and maintain. When all systems use the same defaults—Default Rule, security action, fallback to Allow Communications without Security, same pre-shared key—then you will be able to gain adequate security with minimum impact to your network.

If you decide on a more complex deployment model, consider the benefits of the extra security that you have against the costs of maintaining and running the model. There are two areas to evaluate: maintenance and processor utilization.

Maintenance

If you are considering a deployment model with many customizations and specialized rules, be aware of the time and effort required for ongoing maintenance. Because each system with Intel Packet Protect must be configured individually, customizations require more effort to keep each system up to date.

Consider the previous example of the special rule for the President and Chief Financial Officer (SFO) of the corporation. In order for this rule to work as designed, all aspects of the rule must match, or communication will be denied. If the President's system uses a different setting in the security action from the CFO's system, then a security association cannot be negotiated and therefore all communication is denied. Consider then that it might take several days for the President and CFO to even discover that their communications have not been taking place as assumed.

Even a new system for the president could prevent secure communication from happening. For example, when you set up this special rule, you identified the two systems to Intel Packet Protect by the names of the systems. The President's new system has a new name. When the President and the CFO attempt to communicate the next time, the rule will fail, because of the system name.

You can imagine how difficult it can become to maintain specialized rules, destination workgroups, and security actions in your network. Intel recommends that you begin by using the simple, default model for secure communications. Over time, you can consider customizations to enhance secure communications in special cases.

Processor Utilization

Another very important factor to consider is the effect of IPSec on your network, as well as the individual systems using Intel Packet Protect. Generally, you can assume that when you choose most sophisticated security options, there will be an effect on your network.

One example is choosing to use ESP (Encapsulation Security Payload) and AH (Authentication Header) authentication together. While this combination affords extra protection, you must consider that when you use both of these methods, you can offload only the AH processing to the adapter, and thus CPU utilization increases. However, if you use just ESP authentication with the appropriate adapter, you can take advantage of the hardware offload and get better processor utilization.

You must also consider the adapters that are installed in your Intel Packet Protect systems. Only the Intel PRO/100 S Server Adapter and Intel PRO/100 S Management Adapter can perform hardware offloading. If you have other types of adapters working in Intel Packet Protect systems, you will not be able to offload any processing.

Other security options are considered "costly" as well. Perfect Forward Secrecy is very secure, but if used widely throughout the network, there can be a significant effect on servers that have a lot of secure traffic.


Copyright © 2000, Intel Corporation. All rights reserved.

Intel Corporation assumes no responsibility for errors or omissions in this document. Nor does Intel make any commitment to update the information contained herein.

* Other product and corporate names may be trademarks of other companies and are used only for explanation and to the owners' benefit, without intent to infringe.