Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, Inc.
`ISBN: 0471295264 Pub Date: 09t01!98
`
`‘Previous Table of Contents |Next
`
`Gateways using public-key pairs can be authenticated manually. In such cases, the key pairs are usually
`hard-wired into the device before it’s shipped. The network manager then registers the new device with
`other security gateways on the VPN, giving those gateways the public key so that they can exchange
`session keys.
`
`If a security gateway isn’t shipped with hard-wired keys, the gateway would be Set to randomly generate
`its own key pair. A digital certificate then would be signed with the private key and sent to the
`appropriate certificate authority, either an in-house certificate server or a third-party CA like VeriSign.
`When the certificate is approved, that certificate is available from the CA for use by other security
`gateways and remote clients to authenticate the site before any data is exchanged (see Figure 13.2).
`
`Although these certificates do not need to be standardized (using the X509 standard, for instance) if only
`one vendor’s products are used for the VPN, interoperability between products is possible when X.509
`certificates are employed. More vendors are adopting this approach, which also makes it easier to utilize
`an outside certificate authority for storing the necessary certificates. This might be a necessity if you’re
`expanding your VPN to include partners in an extranet.
`
`Other gateways and remote hosts usually will obtain the appropriate certificate from a CA to authenticate
`the destination gateway by using mechanisms such as LDAP or HTTP to retrieve certificate information
`through a pubtic key infrastructure (PKI) Existing PKIS also require checking certificate revocation lists
`(CRL) to ensure the validity of an existing certificate. However, because the CA hierarchy for verifying
`certificates that we described in Chapter 4, “Security: Threats and Solutions,” can become ungainly, and
`CRLS can become complicated to handle, other mechanisms for verifying certificates are being
`developed and most likely will become available starting in 1999. In particular, the IETF PKIX working
`group has been working on definitions for an interoperable PKI and Onlfne Certificate Status Protocol
`(OCSP). OCSP aims to provide an efficient method for handling compromised or revoked certificates
`(see “Hardware—Based Security” later in this chapter).
`
`FIGURE 13.2 Key exchanges between gateways.
`
`These systems are based on assigning a public-key pair to each security gateway, and the public key is
`published in a directory that’s accessible to all VPN sites. At the start of each encrypted session, the
`session key is scrambled by combining the security gateway’s private key with the recipient’s public key.
`
`220
`
`

`
`Handling Session Keys
`
`If key exchange (such as in IPSec and LZTP) is required between sites, the most basic method is to
`exchange keys manually. An initial session key is randomly generated by one security gateway and then
`the network manager has to deliver the key to the administrator of the second device, by telephone,
`registered mail, or bonded courier, for instance. The second administrator inputs the key to the second
`security gateway, and a secure session between the two gateways can take place. New keys are generated
`as required (perhaps once a week) and distributed in the same fashion as before.
`
`This approach is rather cumbersome and not particularly secure; phone lines can be tapped and mail can
`be intercepted. Dynamic key management, using IKE for instance, is much easier and better suited to
`frequent key changes and large numbers of sites. Session keys are randomly generated, either by the
`initiating security gateway or a key-management server, and distributed over the network. The session
`key itself is scrambled using the recipient's public key before transmission on the net.
`
`Hardware-Based Security
`
`Hardware-based encryption products are less vulnerable to physical attack, which reduces the chances
`of compromised device keys and, therefore, the need to exchange new keys between gateways.
`Whether keys are hard-wired or entered from a management workstation, most hardware encryptors are
`strongly sealed against physical prying and usually erase any stored keys when disturbed.
`
`If session keys are compromised, you’ll need a way to revoke a key pair and assign a new one. The
`procedures for key revocation vary from product to product. How security gateways respond to a revoked
`key also varies among products. The best, most secure method is to drop the session and log the failed
`attempt as soon as a revoked key is detected. Some products wait for a session to be completed before
`denying any fiarther access with that key.
`
`If you’re in a situation where your VPN is restricted to shorter length keys than you would like (due to
`export restrictions, for example), then you should try to improve the security of your VPN sessions by
`increasing the frequency of rekeying. If keys are used for shorter lengths of time, then any attacker will
`have less time to acquire the information he needs to break a key; also, the amount of data that could be
`obtained with a compromised key will be reduced.
`
`Key Management for Users
`
`Generating and distributing keys for LAN-to-LAN VPNS can be a relatively simple process to manage
`when the number of sites is not very large. Even if the number of sites is in the hundreds, a dynamic
`system using an outside certificate authority or in-house certificate server should not involve a great deal
`of management overhead. On the other hand, managing keys for remote users, if they number in the
`thousands, needs to be as scalable and automated as possible. An automated system also is required if
`you plan to use the antireplay protection in IPSec. Distribution of the keys and associated information, in
`particular, may be especially tedious and time-consuming.
`
`Back in Chapter 5, “Using IPSec to Build a VPN,” we pointed out that a pair of IPSec devices has to
`establish a security association with each other in order to communicate. If you’re planning to support a
`large number of remote users with a security gateway, then you’ll need to generate the client security
`
`221
`
`

`
`associations centrally and probably in large numbers. The most practical way is to set up a central site to
`generate all IPSec SA parameters needed and to provide a mechanism to import them into the client. For
`example, a central site could generate SA data in S/WAN format and send the appropriate information to
`each client user.
`
`The IPSec architecture is based on the assumption that hosts assign the Security Parameter Index (SP1)
`for inbound lPSec headers, but the essential requirement is simply that inbound SPIs be unique. If you
`set up a central site for generating keying material and assigning the SPIs to use them, then the client
`software can use those SPIs for communications without having to generate any on their own.
`
`‘Previous [Table of Contents |Next
`
`222
`
`222
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, Inc.
`ISBN: 0471295264 Pub Date: 09i01!98
`
`‘Previous Table of Contents |Next
`
`Protecting Clients Against Theft
`
`Because laptops are particularly susceptible to theft, they pose a special security risk to your VPN
`because the keys stored on a stolen laptop could be used to access corporate resources via the VPN.
`
`There are essentially three techniques for protecting keys from theft:
`
`1. Store the keys on a removable device like a disk or smartcard and carry it separately from the
`clients.
`
`2. Encrypt the keys with a secret password or phrase and require the client to Verify the
`password before lPSec can be used (some smartcards can do this as well).
`
`3. Encrypt the keys with a secret password or phrase and let lPSec processing fail if the wrong
`password is used.
`
`Of these options, the third is the most secure. But, it also can be the most annoying to a legitimate user
`if he accidentally enters the wrong password because he may not be able to discern the reason for a
`communications failure.
`
`Remote VPN users have to be authenticated by security gateways in much the same way as security
`gateways have to identify themselves to each other and be authenticated. The number of options for
`authenticating users are greater, though, and will be covered in the following section. Since the use of
`digital certificates for user identification is becoming more popular and is now being supported by more
`VPN products, we’ll discuss the details of managing certificates for users in “Managing an In-House
`CA” later in this chapter.
`
`Authentication Services
`
`As we discussed in Chapter 4, a variety of ways exist to authenticate users: simple passwords, one—time
`passwords, challengefrcsponse systems using RADIUS or TACACS+, or two-factor systems using
`tokens, as well as digital certificates. If you’re already supporting remote access via a modern bank and
`remote access server, for instance, then you already may have an authentication system in place and
`you’ll just need to link it to your security gateway to control the authentication and access rights of your
`VPN users.
`
`If you're using PPTP, L2F, or L2TP to create tunnels, you might be using your ISP as a tunnel endpoint,
`as we discussed in Chapters 6, “Using PPTP to Build a VPN,” and 7’, “Using L2TP to Build a VPN.”
`Should that be the case, the ISP should be running its own authentication server, which, in turn, is a
`proxy to your authentication server (see Figure 13.3). This enables you to maintain control over setting
`
`223
`
`

`
`authentication parameters and access rights but lets the ISP use that information to provide access to your
`remote users.
`
`Assuming that you may be setting up an authentication system for the first time as you roll out your
`VPN, you can choose from any of the different approaches we mentioned earlier. (See Chapter 4,
`“Security: Threats and Solutions,” for more details.) The better systems are RADIUS, token-based
`authentication, and digital certificates.
`
`RADIUS has three advantages. It’s been standardized by the IETF, and many vendors offer products that
`interoperate. RADIUS also is used by the majority of ISPs for authenticating their customers. Lastly,
`RADIUS can act as a centralized authentication database, drawing on rights defined for users from
`various network operating systems such as NT’s user domains and NDS trees, making it a good platform
`for integration.
`
`Both RADIUS and TACACS+ let you define how to authenticate and pass session variables, such as
`protocol types, addresses, and other parameters. An important feature in both of these systems in the
`capability to define server-based access control policies. These policies can include time-of-day
`restrictions, usage quotas, simultaneous login controls (each user can use only one session at a time), and
`login threshold violations (accounts are looked after X number of consecutive failed logins). RADIUS
`also can be used for accounting purposes, although quota enforcement requires constant tracking of each
`user’s time online and can become a relatively complex task.
`
`‘In
`
`A RADIUS server usually consists of three main files: a database of authorized users, a file of client
`access servers that are authorized to request authentication services, and a set of customized options,
`called dictionaries, for each remote access server or security gateway. If you were configuring RADIUS
`for use with an ISP and PPTP, for instance, you would add the name or address of the ISP’s proxy server
`to the file of client access servers and define a new dictionary for that server, describing any special
`authentication and authorization features for the server. (TACACS+ does not include dictionaries in its
`architecture.)
`
`Token-based authentication usually requires using a special reader attached to the workstation or laptop
`and a token card that generates special passcodes that are checked by a secure server on the network
`before access is granted to the user. Before users are permitted to authenticate themselves, token devices
`request a PIN. Two of the more popular mechanisms for verifying users are a challenge—response system
`(see Chapter 4) or time synchronization, which depends on synchronized clocks and a frequently
`changing secret key that the user has to enter when logging in. Although tokens are a very secure method
`for authentication, because they use a two-factor method (i.e., something the user has—the token
`card—and something the user knows—the PIN), they can prove to be awkward to use because of the
`additional hardware that’s required.
`
`It’s also possible to use digital certificates for authenticating users, although these systems aren’t nearly
`as widespread as RADIUS servers. That’s likely to change with time. Some of your employees already
`may be using personal digital certificates with their Web browsers or e-mail clients. If you’re already
`
`224
`
`

`
`sending secure e—mail that requires digital certificates and a public—key infrastructure (see Chapter 4),
`then you could use the same system for issuing and storing the digital certificates required for
`authentication on the VPN. If not, you’ll have to set up an appropriate certificate authority for your users;
`this could be either a commercial CA like Verisign or an in—house certificate server that you maintain.
`
`Using a third-party certificate authority can make certificate management easier, because it’ll be
`accessible via the Internet and would be more readily accessible to any extranet partners. But, if you’re
`supporting only internal users (i.e., corporate employees), an in—house CA should work just fine. Since
`your security gateways will be performing authentication of the VPN’s users, outside access to the digital
`certificates isn’t necessary. But, you’ll still need to secure the computer used for issuing and storing
`digital certificates, as well as any backup files or tapes (see the next section).
`
`[Previous [Table of Contents ‘Next
`
`225
`
`225
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, Inc.
`ISBN: 0471295264 Pub Date: 09i01!98
`
`‘Previous Table of Contents |Next
`
`Whichever course you choose, you’ll need a way to initially distribute to each user the approved digital
`certificates and the private keys they contain. Outside CA5 normally handle certificate distribution via
`e-mail or HTTP. If you’re running your own certificate server, you can do the same, but you also might
`choose a physical means, such as a floppy disk or smart card. Many companies are employing smart
`cards for distributing and storing digital certificates because of their portability and the fact that they also
`can be further secured with a user-specific PIN that makes the card useless if lost or stolen. Plus, these
`cards shut down after a series of failed login attempts.
`
`Managing an In-House CA
`
`Digital Certificates have a limited lifecycle (see Figure 13.4); after they’re issued, they should be expired
`after a reasonable period of time (6 months, for instance) or may be revoked if the owner changes jobs or
`his private key is compromised. Certificates also can be renewed and need to be backed up in case keys
`need to be recovered at a later date. If you want to run your own certificate authority in-house, managing
`the system will involve not only creating key pairs and issuing certificates but also managing those keys
`and certificates. Certificate management includes maintaining a certificate repository, revoking
`certificates as needed, and issuing certificate revocation lists (CRLS). Key management involves key
`backup and recovery, automatic updates of key pairs (and their certificates), and management of key
`histories.
`
`As you plan the deployment of a private certificate server, keep in mind that the infrastructure for digital
`certificates and certificate management is still in a relatively early stage of development. The use of
`CRLs for monitoring revoked certificates is also inadequate for dynamic situations, such as you’re likely
`to encounter with remote users accessing a VPN. But, new solutions, like Online Certificate Status
`Protocol (OCSP), are also under development. Furthermore, commercially available certificate servers
`still need improvement of their support for administrative tasks. In-house CA systems can be purchased
`from Certco lnc., Entrust Technologies Inc., GTE CyberTrust Inc., Microsoft Corp., Netscape
`Communications Corp., Security Dynamics Technologies Inc., and Xcert Software Inc. Some VPN
`product vendors include a CA as an option, although many of these products are software-based CA3
`installed on a workstation. Radguard offers a sealed hardware-based CA for use with clPro.
`
`4 The lifecycle of digital certificates.
`
`226
`
`

`
`OCS P: A Dynamic Way to Track Certificates
`
`There currently is no practical way to revoke a certificate if the password that unlocks a user’s
`certificate is breached or when the user’s private key is compromised. The only solution certificate
`servers offer right now is the CRL. Ultimately, we’ll be looking to the PKIX standard and OCSP for a
`real solution.
`
`The only way you can use CRLS is by laboriously matching up two lists (the list in your local storage
`and the one in the CRL) and deleting certificates by hand. OCSP moves away from this static—list
`model toward a more dynamic one. OCSP defines LDAP and HTTP status queries that are designed to
`provide fast response time and high availability. In response to a client query, an OCSP server sends a
`simple status message—valid, invalid, revoked, not revoked, or expired. Using this model, the load is
`balanced between the client and the server, and it becomes possible to do real-time certificate checking
`on a per-transaction basis.
`
`Despite these problems, a private certificate server can be installed and managed within your corporation
`to authenticate both security gateways and users on your network. Let’s take a look at some of the
`features that a useful certificate system should include.
`
`The basic task of a certificate server is to accept requests for new certificates, queue them for their
`review by the system administrator, and issue the certificates for client retrieval (see Figure 13.5). In
`general, certificate servers accept certificate requests from a certificate-management workstation, when
`an administrator is perfonning batch issues of certificates, or from individuals themselves via HTTP or
`e-mail. Whenever new requests for certificates are received, they should be matched against certificates
`held in the directory to prevent accidental obsolescence of valid public keys. The user‘s certificate can be
`presented to its owner via HTTP or e-mail as well, or transferred to a disk or smart card for manual
`distribution.
`
`The private keys of each public-key pair that’s issued should be stored within a central repository that’s
`secured against unauthorized access. This repository also should be backed up in a secure fashion
`(usually as encrypted files), because it becomes part of the key-recovery system should older messages
`need to be decrypted if a key is lost or compromised and revoked. Backup tapes must be carefully
`guarded and strictly accounted for.
`
`Since you’ll be signing all issued certificates as a certificate authority, a special, dedicated workstation
`will need to be set up for storing the private keying material (your root certificate, as it’s called); this
`Same workstation also will include any of the software (and any special hardware, if it’s required) for
`collecting, signing, distributing, and revoking certificates. This workstation should be physically secured
`against unauthorized access; it should not be treated as a multipurpose computer.
`
`‘Previous [Table of Contents lhlcxt
`
`227
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, Inc.
`ISBN: 0471295264 Pub Date: 09i01!98
`
`‘Previous Table of Contents |Next
`
`Because one of the purposes of digital certificates is to distribute a public-key pair, the certificate system
`needs a way of making the public key available to those who need it. The usual method is to store the
`public keys in a directory. Although large-scale master directories for certificates may be based on
`X500, there’s been a significant move to use another protocol, Lightweight Directory Access Protoco!
`(LDAP), to utilize much of the structure of X500, but over TCP/IP. Many certificate servers now offered
`for use at corporate sites are based on LDAP. The increasing popularity of LDAP for directory access
`also will make it easier for you to link other directory-based services to your digital certificates.
`
`u
`
`I
`_
`-.—..-1--1
`Fl-C:URli‘. 13.5 Generating and certifying a public key.
`
`Certificate servers also have to maintain and make available a Certificate Revocation List which lets
`
`users know which certificates are no longer valid. Certificates may be revoked because they were lost,
`stolen, or because an employee left the company, for example.
`
`For small numbers of digital certificates, a single centralized certificate server will most likely suffice.
`But, if the number of certificates that the company requires is large, using multiple certificate servers
`arranged in some sort of hierarchy (perhaps based on departments) will be more manageable and more
`reliable because the system no longer has a single point of failure. Some certificate servers support
`multiple levels of administration; one group can perform certificate approval and revocation tasks, for
`instance, and another group can perform these functions as well as assign certificate authority to
`subordinate CA3. This makes it possible to set up distributed administration by assigning responsibility
`for a portion of the directory tree to another CA and set of administrators.
`
`You also should be able to set certain parameters for the clients from your central system; these
`parameters should include defaults such as approved directory servers and certificate signers.
`
`The task of supporting user access to certificates will become much easier if your system can support
`more than one method for requesting and receiving a certificate. At a minimum, clients should be able to
`perform these tasks using HTTP, e-mail, and disk files. As we’ve said before, smart cards are also
`becoming an increasingly attractive alternative for distributing and storing digital certificates.
`
`Users should be informed of the need to properly store and protect their certificates. The previous sidebar
`on protecting clients against theft includes some suggestions for protecting their certificates.
`
`Lastly, expect the client software to provide automatic checking of a certificate’s validity using CRL
`
`228
`
`

`
`downloads (in the background, for offline use). When OCSP becomes available, look for software that
`supports it so that certificates can be immediately verified online.
`
`Controlling Access Rights
`
`Even though a VPN is architected to provide communications between hosts and security gateways, it‘s
`likely that you’ll still want to maintain some control over the access that each VPN user has to network
`resources. For instance, if sales department personnel are not allowed access to R and D resources when
`they’re on a hard-wired LAN, they should still be restricted from that access if they dial into the VPN
`while they're on the road. This means that you’ll have to merge the control of the new access routes
`provided by your VPN with the access controls currently programmed into your routers and firewalls.
`
`VPN traffic can be handled in two different ways by a firewall, either as unfiltered packets or as filtered
`packets (see Figure 13.6). In the unfiltered approach, the VPN traffic is handled the same way it is in a
`router; that is, the protected data is transferred directly to the internal network without any filtering or
`controls on its contents. In the filtered approach, the firewall’s filter and proxy controls are applied to the
`VPN traffic before it is allowed into the internal network. Filtering VPN traffic can be particularly useful
`if your security policy is to pass only certain types of traffic between VPN sites, say e—mail and FTP.
`Filtering also can be useful for controlling the traffic exchanged with business partners if you expand
`your VPN to an extranet.
`
`IFIFCURE 13. _ Fiirewalls filtering VPN.
`
`If you place the gateway between the Internet and the router, then the router (and subsequent firewalls)
`can be used to filter both VPN and non-VPN traffic with the same rules; the gateway will provide
`transparent encryption and decryption services to the entire site. Also, the router doesn’t need to be
`reconfigured to pass special tunnel traffic, which is the case when a gateway is installed behind the
`router. One caution: If the gateway is on the public, or untrusted, side of the network, you need to ensure
`that management of the gateway Cannot be compromised from someone on the untrusted net. If this link
`is handling both VPN and non-VPN traffic, then the VPN gateway needs to be configured to pass
`non-VPN traffic.
`
`When you locate the gateway behind a router or firewall, the control device would have to be configured
`to pass VPN traffic without filtering. Although this increases the security of the gateway (it’s less
`susceptible to compromising the management port, for instance), it also means that you have less control
`over the traffic entering the LAN after decryption by the gateway. If you want to filter VPN traffic by
`destination, time-of-day, or application type, for instance, then you have to duplicate the filters from your
`router or firewall on the gateway.
`
`229
`
`

`
`Summary
`
`Much of the management of security for VPNS is a straightforward extension of standard corporate
`security policies, especially for authentication of users and control of their access to network resources.
`However, VPNS do require added knowledge of the strengths and weaknesses of different encryption
`algorithms and associated key lengths so that the data transmitted on a VPN is properly protected.
`
`The distribution of keys to authenticate security gateways and remote hosts on a VPN is an important
`part of VPN management, with many systems employing digital certificates for this task. Either
`commercial certificate authorities or a private in—house certificate server can be used to issue and control
`distribution he digital certificates.
`
`{Previous [Table of Contents |Next
`
`230
`
`230
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, inc.
`ISBN: 0471295264 Pub Date: 09l01l98
`
`Previous Table of Contents |Next
`
`CHAPTER 14
`
`IP Address Management
`
`The explosive growth in the use of IP for data communications, both within and among enterprises, has
`led to a number of problems in the allocation and management of IP addresses. Although the original
`32-bit address space of IPV4 may have seemed sufficient to handle any network’s requirements when it
`was first described, there is a growing concern that IPV4’s address space will soon prove inadequate, at
`least for the public Internet. (Private internetworks are another matter, as we’ll see shortly.) The next
`generation of IP, version 6 or IPv6, features a 128-bit address space, which should be suitable for some
`time, but until it’s deployed globally, other shortaterm solutions to address shortages have been put into
`place. Unfortunately, although these short—term solutions help network managers deal with current day
`addressing and routing problems, they can cause problems for those of us deploying VPNS.
`
`Although IPSec, as well as many other protocols, may be best suited for use with IPv6, most of us have
`to deal with the current situation surrounding the continued use of IPv4 and the added complexity that
`various short—term solutions bring with them. Because IPv4 is likely to stay around for the next few
`years, VPN design and deployment has to accommodate the complexities surrounding address
`management even as network engineers look for other solutions that will make addressing easier to use
`within VPNS.
`
`To help point out some of the addressing problems VPN designers and managers face, this chapter
`covers the current methods for allocating addresses to network devices, both on public and private
`networks, as well as the related task of naming network entities via the Domain Name Service (DNS). As
`we go along, we’ll point out some of the special problems VPNS may incur. Wherever possible we’ll also
`discuss some of the current solutions proposed to counter these problems.
`
`Address Allocation and Naming Services
`
`For large enterprises, allocating IP addresses among thousands of workstations and servers and
`configuring these addresses in TCP/IP software is often a daunting task. In the past, adding, moving, or
`changing workstations and servers required manual assignment of new IP addresses. Simplistic
`approaches to tracking addresses, such as a notebook or electronic spreadsheet, may work for small
`networks, but these approaches quickly prove to be inadequate as networks get larger. Automated servers
`and related tools have to be employed to ensure that the networks run smoothly. Foremost among these
`for IP networks are Dynamic Host Control Protocol {DHCP) for address management and DNS for name
`management; and now, using Dynamic DNS to link the two makes network management easier, although
`
`231
`
`

`
`not foolproof.
`
`A variety of problems can result from inadequate tracking of network addresses. Without proper
`tracking, addresses can be lost during equipment changes or moves just when network growth is leading
`to address scarcity. Not knowing which addresses are assigned can lead to mistakenly assigning the same
`address to two different machines, which leads to loss of connectivity and routing problems.
`
`Another difficult task is allocating addresses for mobile users. Roaming sales reps with laptops may have
`to be provided with multiple network addresses, one for each router or remote access server that they
`might access via a dial connection leading to a waste of addresses and further tracking nightmares.
`Multiple addresses aren’t needed when you convert the users of your remote access servers to a VPN, but
`you may still want to dynamically assign an address rather than use static allocations.
`
`The current state of allocating addresses to companies also causes problems. Companies requiring
`addresses for more than 1,000 devices cannot obtain Class A or B network addresses and usually are
`forced to use Classless 1mer—D0ma:'n Routing (CIDR) to combine available Class C addresses. But,
`using CIDR requires contiguous network numbers, leading to grouping networks by region so that all
`network numbers within a given region can be represented by a single entry in the routing tables of other
`regions (see Figure 14.1). If addresses for devices in a given region are not allocated contiguously, then
`routing table aggregation cannot be performed, and router performance will be reduced.
`
`Static and Dynamic Address Allocation
`
`In the past, an IP address was usually allocated by hand to a network device such as a router, server, or
`workstation when the device was attached to the network. (Printers and other devices using BOOTP are
`exceptions.) These addresses corresponded to the subnet in which the device was located—l72.52.X.X
`for Human Resources versus l72.53.X.X for R and D, for instance—and had to be changed if the
`computer was relocated to another subnet. Furthermore, a device’s address was static and didn’t change
`unless someone (usually the network manager) changed the device’s configuration file.
`
`Allocating IPv4 Addresses
`
`IP addresses are divided into three major classes: A, B, and C. (A fourth class, D, is reserved for special
`uses such as multicasting.) Each ad—dress consists of four octets, or sets of eight binary digits, separated by
`decimals. The first octet determines the class of the IP address. Class A addresses use the last three octets to
`
`specify IP nodes; Class B addresses use the last two octets for this purpose; and Class C addresses use the
`last octet.
`
`Class A network addresses are the most desirable, because they are large enough to serve the needs of any
`size enterprise (see Table l4.l). But since fewer than [28 Class A networks can exist in the entire Internet,
`they are very scarce, and no more Class As are being allocated. Only those organizations that were early
`users ofthe Internet (e.g., Xerox Corp., Stanford U., BBN) are in possession of Class A networ