![]() ![]() IPSec For Communities Of Interest |
By Robert Moskowitz
With IPSec, organizations can create private communities of interest without regard for the specifics of the networks involved. We'll explore the technologies that make up IPSec and, in describing each, provide you with a better understanding of the technology. IPSec Protoc ols IPSec consists of two protocols: the Authentication Header, or AH protocol, and the Encapsulating Security Payload, or ESP protocol. The AH protocol creates an envelope that provides integrity, data origin authentication and protection against replays (see "Authentication Header Format" on page 104). Thus, AH provides a number of defenses against intruder attacks. This protocol authenticates every packet, so session-stealing programs are rendered ineffective. In addition, its basic replay counter can stop replay attacks that might contain bogus or destructive data. AH also provides authentication for as much of the IP header as possible, even though the IP header is outside the AH envelope. AH authentication precludes the manipulation of IP header fields while the packet is in transit. This feature makes AH unsuitable for use in a NAT (Network Address Translation) end-to-end environment because manipulating IP headers is a required NAT function. The ESP protocol provides data privacy (see "Enca psulating Security Payload Format" on page 104). It includes all of the functions of AH to protect against attacks on encrypted, nonauthenticated data streams. The IPSec specification does allow for ESP without the AH functions, but we strongly recommend against using it this way unless you fully understand what you are doing. ESP also can use null encryption, which amounts to AH without the authentication of the IP header. This can allow for NAT traversal, since the addresses in the IP header are mutable. ESP and AH are registered by the IANA (Internet Address Naming Authority) as Protocols 50 and 51 respectively. If you or your service provider have implemented some basic packet-filtering rules in your border routers, then you'll need to add these protocols to your allowable list. Because the protocol-type field in the IP header is now that of the IPSec envelope, the original transport type is moved to the next protocol field within the IPSec header (see "Protocol Encapsulation" on page 106). The IPS ec protocols can be used in either transport or tunnel mode. In transport mode, IPSec slides into the normal IP packet between the network (IP) and transport (TCP or UDP) envelopes. Transport mode was developed for use by end systems. Its use is predicated on full deployment to all systems in the group and most cases will require reprogramming of applications. IPSec's tunnel mode was developed for use by gateways. In tunnel mode, a normal IP packet is placed into an IPSec envelope, which in turn, goes into another IP envelope. In this mode, you can rapidly deploy IPSec tunnel devices at the perimeter of a network. Securing traffic between similarly configured networks is simple and requires no new application development or special end-user software. Software supporting tunnel mode may run on a gateway or on end systems. The most common use for tunnel software on an end system is to support remote and mobile users. Although gateways send most end-user data via tunnels, they might use transport mode to p rotect housekeeping communication among peer gateways. This would be an excellent way to secure remote management of routers, ATM switches, firewalls and other key infrastructure components, for example.
|
|
|
|
Network Monitor Finally Comes Out of Hiding By J. Scott Haugdahl Virtual Private Networks: Harder Than You Think IPv6 For VPNs: It's Looking Better All The Time The Battle Of The Logon Titans |
|||||||||||||||
|
|
![]() |
|
|



our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at 










