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).
`
` IFFBVITEUS
`
`
`Of‘ O1"ll6l'llS lfiext
`
`Petitioner Apple Inc. — EX. 1006, p. 225
`
`Petitioner Apple Inc. - Ex. 1006, p. 225
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, inc.
`
`‘ ISBN: 0471295264 Pub Date: o9ro1r93
`
`{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 I'l.ll1 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 lnc., GTE CyberTrust lnc., Microsoft Corp., Netscape
`Communications Corp., Security Dynamics Technologies lnc., 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.
`
`Petitioner Apple Inc. - Ex. 1006, p. 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 performing 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 {Next
`
`Petitioner Apple Inc. - Ex. 1006, p. 227
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, Inc.
`ISBN: 0471295264 Pub Date: 09i01!98
`
`lPrevious 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 Protocol
`(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:URl':‘. 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
`
`Petitioner Apple Inc. - Ex. 1006, p. 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 l3.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.
`
`FTCUWRE 13.6 Firewalls 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.
`
`Petitioner Apple Inc. - Ex. 1006, p. 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
`
`Petitioner Apple Inc. — EX. 1006, p. 230
`
`Petitioner Apple Inc. - Ex. 1006, p. 230
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, lnc.
`
`‘ ISBN: 0471295264 Pub Date: o9ro1r93
`
`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 short—-term 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—tern1 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
`
`Petitioner Apple Inc. - Ex. 1006, p. 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 network addresses.
`
`Petitioner Apple Inc. - Ex. 1006, p. 232
`
`

`
`TABLE 14.1 Properties of IPv4 Address Classes
`
`Class
`
`Network ID
`
`# Unique networks
`
`A
`
`B
`
`C
`
`7 bits
`
`14 bits
`
`21 bits
`
`128
`
`>l6,000
`
`>2,000,000
`
`Host address # Unique
`ID
`hosts
`
`24 bits
`
`16 bits
`
`8 bits
`
`16,777,216
`
`65,536
`
`256
`
`The more than 16,000 possible Class B networks also have become scarce and are now difficult to obtain.
`There is a large supply (over 2 million) of Class C network addresses, so they are still plentiful. The major
`problem is that for most organizations, a Class C network is too small (only 256 unique Host IDs). Even a
`Class B network is not large enough for an enterprise with more than a thousand LANs.
`
`l l |Next
`
`Petitioner Apple Inc. — EX. 1006, p. 233
`
`Petitioner Apple Inc. - Ex. 1006, p. 233
`
`

`
`.t...r .. ..d '.o'...-.
`....
`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Wiley Computer Publishing, John Wiley & Sons, inc.
`ISBN: 0471295264 Pub Date: 09i01l98
`
`Previous Table of Contents |Next
`
`But, networks are far from static: Equipment gets changed or upgraded; people and equipment are
`moved; and networks rearchitected. Manually assigning static IP addresses is time—consuming when any
`changes are necessary; it also can be an error—prone process. To help deal with this continuing problem,
`a dynamic method for allocating addresses, the Dynamic Host Control Protocol (DHCP) was developed.
`And, since users normally are more comfortable with names rather than numeric addresses for network
`devices, the standard naming service, Domain Name Service (DNS), also was modified so that it could
`dynamically link with DHCP and track any changes made by DHCP.
`
`DHCP is designed to provide a centralized approach to the configuration and maintenance of an IP
`address space, allowing the network administrator to configure various clients on the network from a
`single location. DHCP permits IP address leases to be dynamically assigned to workstations, eliminating
`the need for static IP address allocation by network and systems management staff. Pools of available IP
`addresses are maintained by DHCP servers.
`
`DHCP operation is fairly straightforward. When a DHCP client workstation boots, it broadcasts a DHCP
`request asking for any DHCP server on the network to provide it with an IP address and configuration
`parameters. A DHCP server on the network that is authorized to configure this client will offer an IP
`address by sending a reply to the client. The client can either accept it or wait for additional offers from
`other servers on the network. Eventually, the client selects a particular offer notifying the proper server.
`The selected server then sends back an acknowledgment with the offered IP address and any other
`configuration parameters that the client might have requested.
`
`DHCP servers aren’t restricted to assigning only dynamic addresses. A set of addresses can be set aside
`as static network addresses for assignment to specific clients, such as file and mail servers. The DHCP
`server treats the lease periods for each of these static addresses as infinite.
`
`The IP address offered to the client by a DHCP server has an associated lease time, which dictates how
`long the IP address is valid. During the lifetime of the lease, the client usually will ask the server to
`renew. If the client chooses not to renew or if the client machine is shut down, the lease will eventually
`expire, and the IP address can be given to another machine.
`
`The Domain Name Service (DNS) is the Internet’s official naming system and is designed to name
`various network resources, including IP addresses. DNS is a distributed naming system—the database
`that translates names to objects is scattered across many thousands of host computers.
`
`Domain name requests (i.e., requests to convert a network name into its corresponding network address)
`are handled by a hierarchy of DNS servers (see Figure 14.2). Requests are sent first to the local (i.e.,
`lowest level) nameserver in the network hierarchy, with the IP address of this nameserver typically
`configured in each workstation’s TCP/IP software. If this nameserver cannot answer the query, it sends
`
`Petitioner Apple Inc. - Ex. 1006, p. 234
`
`

`
`the request to a higher level nameserver. This higher level nameserver can either resolve the name
`request itself or obtain information from a lower level nameserver that’s unknown to the original
`requester. For example, the marketing and sales subdomains at Big Company may have nameservers at
`the same level in the DNS hierarchy, but the only way that users in marketing can obtain name
`information from the sales nameserver would be to request it via the bigcompany.com higher level
`nameserver.
`
`In the past, DNS was designed to work with static IP addresses. A relatively new feature, Dynamic DNS
`(DDNS), has been defined by the IETF (RFC 2136) and now is provided by some vendors for their
`DHCP servers to automatically pass IP address lease-assignment information to DNS servers. This
`permits workstations with addresses assigned dynamically by DHCP to be tracked by DNS servers;
`workstations are then reachable by a name without manually maintaining the DNS database (see Figure
`14.3).
`
`Even though DHCP and Dynamic DNS can simplify IP address management, DI-lCP’s dynamic
`allocation of IP addresses can cause other problems. Some firewalls and other Internet security products
`track IP addresses on the assumption that an IP address uniquely identifies a computer. If these products
`cannot map a DHCP—assigned address back to a specific user, an unauthorized user may gain access to
`the network because the address is authorized to go beyond the firewall, but the user is not.
`
`Similarly, any attempt to debug problems on a live network relies on being able to translate an IP address
`to a particular user’s computer. Other problems that can arise from dynamic IP address assignments
`might include control of content filtering (i.e., restricting Web browsing to certain sites), as well as
`billing and chargeback.
`
`Dynamic address assignments can create problems for your security setup unless you’re prepared for
`them. Because firewalls often match access rights to IP addresses, systems supporting DHCP should
`allow for the reservation of a batch of IP addresses for a specific group of users (a specific named team
`or department, for instance). As long as those same IP addresses are the ones allowing firewall traversal,
`use of the firewall can be controlled on a group basis, even when IP addresses are dynamically assigned.
`
`....._...
`
`.-c'—5'p_
`
`._*i'.'
`
`L.
`_..,n,,_.
`"E35-ea.
`FIGURE 14:2 A "hierarchy of DNS servers.
`
`l
`
`3:.-—«---..-u.—_.
`-on-as--n
`In-u.n:.....g.._.::_
`0 l..'."‘;".".‘..".; 1
`i~"1(;'UR1«:"'14:3 Coupling DHCP and dynamic DNS.
`
`Although DHCP and DDNS are a nice fit, you can use DHCP without DDNS. In that case, not all
`devices on your net should have their addresses assigned dynamically. When assigning IP addresses to
`the file, mail, and other important servers on your net, static address assignment should be used. This
`makes it possible to use DNS to directly map network names to network addresses. Similarly,
`workstations that assume server functionality (e.g., personal Web servers) will normally also need static
`addresses so that they can be tracked by DNS.
`
`Petitioner Apple Inc. - Ex. 1006, p. 235
`
`

`
`Internal versus External DNS
`
`When you’re protecting external access to your intranet, say with a firewall or a security gateway, you
`have to take extra steps to protect your Domain Name Services while still allowing your users to access
`outside resources when necessary (and allowed). This usually involves setting up what is often called a
`double DNS scheme.
`
`For a private IP network, your corporate DNS server would have sufficed, because it could take care of
`all address—name translations for the network, and the lack of a connection to the public Internet would
`help keep outsiders from discovering the names of corporate computing resources.
`
`The first problem arises when you have a connection to the Internet and some corporate employees need
`access to resources on the outside. To properly map names to addresses, your corporate DNS server has
`to communicate with an external DNS server, presumably one hosted by your ISP. But, because you
`don’t want outsiders to access your internal resources, you need to protect your internal DNS server
`(along with other network resources), so you install a firewall. Since the ISP’s DNS server is outside the
`firewall, and your corporate DNS server is inside the firewall, they cannot readily communicate, which
`keeps employees from accessing outside resources as well as the reverse.
`
`lPrevious lTable of Contents ‘Next
`
`Petitioner Apple Inc. — EX. 1006, p. 236
`
`Petitioner Apple Inc. - Ex. 1006, p. 236
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, inc.
`
`‘ ISBN: 0471295264 Pub Date: o9ro1r93
`
`{Previous Table of Contents |Next
`
`The solution is to install two corporate DNS servers: one on the outside of the firewall and one inside it.
`This is the double DNS scheme. The next step is to separate the hosts that had been on your sole DNS
`server into two groups. The first group lists those hosts that you want anyone on the Internet to find, such
`as your ewmail gateway, public Web site, and anonymous FTP server, for instance; it’ll also include the
`name of the firewall’s external interface. The second list contains the set of hosts that only your internal
`network users will be able to find. Don’t forget that the second list also should include the external hosts
`that your internal users must be able to find.
`
`As you might expect, the external DNS server stores the first list, and the internal DNS server stores the
`second list. The external DNS server is advertised to the Internet as the authoritative DNS server for your
`domain, which means that requests from Internet—based hosts will reach the external DNS server, but not
`the internal DNS server.
`
`The hosts on your internal network use the internal DNS server as their primary DNS server. When they
`want to access external hosts, the internal DNS server will forward DNS resolution requests to the
`external DNS server outside the firewall. This is accomplished because the internal DNS server would be
`configured with aforwarders entry telling it where to find the external DNS server. Because the requests
`have to pass through the firewall, a DNS proxy service is set up on the firewall, allowing it to make a
`separate connection to the external DNS server on behalf of the internal DNS server (see Figure 14.4).
`
`You may encounter similar situations with your VPN. If you’re using an internal DNS server and
`shielding your DNS entries from the rest of the world, then you’ll need a way to provide this information
`to the other sites and remote users of your VPN so that they can complete connections to appropriate
`resources. If you intend to allow access to a limited number of hosts on your VPN, then you could try
`maintaining dual DNS entries: one set for internal usage and the second for VPN use.
`
`Private Addresses and NAT
`
`The blocks of IP addresses allocated by the IANA are meant for use on the public Internet. If your
`company had no intention of using the Internet, but would transmit only IP traffic on its own
`internetwork, then any range of addresses can be used. Even then, the IETF recommends that only
`certain ranges be used so that Internet routers would not be confused if the addresses were inadvertently
`
`Petitioner Apple Inc. - Ex. 1006, p. 237
`
`

`
`advertised on the Internet. These blocks, which are defined in RFC 1597, “Address Allocation for Private
`Subriets,” are as follows:
`
`Class A l0.0.0.0—l0.255.255.255
`
`Class B 172.l6.0.0—l72.31.255.255
`
`Class C 192.l68.0.0—192.l68.2S5.255
`
`lt’s possible to use these private addresses for an internal internetwork and still connect to the Internet.
`To do so, you need to be allocated a block of registered addresses and use a firewall or router that
`performs network address transiation (NAT).
`
`NAT converts your inside addressing schemes into the registered addresses prior to forwarding the
`packets to the public lntemet. The translation is fully compatible with standard routing functionality and
`features; NAT needs to be applied only on the router or firewall that is connected physically to both
`inside and outside addressing schemes.
`
`NAT is interface independent, meaning that NAT can be applied to any interface on the router that links
`inside to outside addressing schemes. In Figure 14.5, the host system is using a privatized IP address of
`10.2.2.1 as part of the intranet. When the packet reaches the router, NAT translates the 10.2.2.1 a