throbber
United States Patent
`Wesinger, Jr. et al.
`
`[19]
`
`[54] FIREWALL PROVIDING ENHANCED
`NETWORK SECURITY AND USER
`TRANSPARENCY
`
`[75] Inventors: Ralph E. Wesinger, Jr., San Jose;
`Christopher D. Coley, Morgan Hill,
`both of Calif.
`
`[73] Assignee: Network Engineering Software, San
`Jose, Calif.
`
`[21] Appl. No.: 08/733,361
`[22]
`Filed:
`Oct. 17, 1996
`
`[51] Int. Cl.6 ...................................................... .. G06F 1/00
`[52] US. Cl. .............................. .. 395/187.01; 395/200.55;
`395/200.57
`[58] Field of Search ............................. .. 395/186, 187.01,
`395/188.01, 200.3, 200.55, 200.68, 200.57;
`380/3, 4, 21, 23, 25; 340/8253
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`4,713,753 12/1987 Boebert et al. ....................... .. 364/200
`
`4,799,153
`4,799,156
`
`1/1989 Hann et al. . . . . . . .
`1/1989 Shavit 61 al. ..
`
`. . . .. 380/25
`364/401
`
`5,191,611
`
`3/1993 Lang . . . . . . . . .
`
`. . . . .. 380/25
`
`5,241,594
`5,416,842
`
`380/4
`8/1993 Kung ..
`5/1995 AZIZ ........................................ .. 380/30
`
`(List continued on next page.)
`
`OTHER PUBLICATIONS
`
`Kiuchi et al., “C—HTTP The Development of a Secure,
`Closed HTTP Based Network on the Internet”, PRoceedings
`of SNDSS, IEEE, pp. 64—75, Jun. 1996.
`Neuman, “Proxy Based Authorization and Accounting for
`Distributed Systems”, IEEE, pp. 283—291, 1993.
`Network Firewalls; IEEE Communications Magazine; (Ball
`ovin et al.) pp. 50—57; Sep., 1994.
`The MITRE Security Perimeter; IEEE Communications
`Magazine; (Goldberg); pp. 212—218; 1994.
`
`US005898830A
`Patent Number:
`Date of Patent:
`
`[11]
`[45]
`
`5,898,830
`Apr. 27, 1999
`
`IpAccess—An Internet Service Access System for Firewall
`Installations; IEEE Communications Magazine; (Stempel);
`pp. 31—41; 1995.
`Remote Control of Diverse Network Elements Using
`SNMP; IEEE Communications Magazine; (Aicklen et al.);
`pp. 673—667; 1995.
`Firewall’s Information is Money!, Scienti?c Management
`Corporation.
`Primary Examiner—Joseph Palys
`Attorney, Agent, or Firm—McDonnell Boehnen Hulbert &
`Berghoff
`[57]
`
`ABSTRACT
`
`The present invention, generally speaking, provides a ?re
`wall that achieves maximum network security and maxi
`mum user convenience. The ?rewall employs “envoys” that
`exhibit the security robustness of prior-art proxies and the
`transparency and ease-of-use of prior-art packet ?lters, com
`bining the best of both worlds. No traffic can pass through
`the ?rewall unless the ?rewall has established an envoy for
`that traffic. Both connection-oriented (e.g., TCP) and con
`nectionless (e.g., UDP-based) services may be handled
`using envoys. Establishment of an envoy may be subjected
`to a myriad of tests to “qualify” the user, the requested
`communication, or both. Therefore, a high level of security
`may be achieved. The usual added burden of prior-art proxy
`systems is avoided in such a way as to achieve fall
`transparency-the user can use standard applications and need
`not even know of the existence of the ?rewall. To achieve
`full transparency, the ?rewall is con?gured as two or more
`sets of virtual hosts. The ?rewall is, therefore, “multi
`horned,” each home being independently con?gurable. One
`set of hosts responds to addresses on a ?rst network interface
`of the ?rewall. Another set of hosts responds to addresses on
`a second network interface of the ?rewall. In one aspect,
`programmable transparency is achieved by establishing
`DNS mappings between remote hosts to be accessed through
`one of the network interfaces and respective virtual hosts on
`that interface. In another aspect, automatic transparency may
`be achieved using code for dynamically mapping remote
`hosts to virtual hosts in accordance with a technique referred
`to herein as dynamic DNS, or DDNS.
`
`21 Claims, 9 Drawing Sheets
`
`, FIREWALL I
`
`'151
`
`54
`
`107"
`
`FIREWALL
`DNS/DUNS
`
`118
`
`5.4
`
`109
`
`no
`
`7 l6
`
`FIREIVAIJ/
`
`ADDRESS SUBSET:
`
`EU. 192,168.3(X
`
`:
`
`9
`
`166
`
`\"IRIUA l , HOS'I
`MACHINE
`
`/ .
`
`ADDRESSES
`
`@LI
`7‘
`III.
`
`115
`
`4G ' SUBSET
`
`153
`
`151
`
`Petitioner Apple Inc. - Ex. 1044, p. 1
`
`

`
`5,898,830
`Page 2
`
`US. PATENT DOCUMENTS
`
`1/1996 Yoshida etal- ------------------ -- 395/187-01
`5,483,661
`2/1996 Kaufnman etal- --------------------- -- 380/30
`5,491,752
`2/1996 Linehan et a1.
`380/21
`5,495,533
`8/1996 Denslow
`395/187.01
`5,548,721
`8/1996 Gelb ......... ..
`395/187.01
`5,550,984
`5,577,209 11/1996 Boyle et a1. ........ ..
`395/200.06
`5,590,199 12/1996 Krajewski, Jr. et a1.
`380/25
`
`2/1997 Chen et a1. ............................. .. 380/21
`5,602,918
`2/1997 Shwed .... ..
`395/200.11
`5,606,668
`4/1997 Vu .................................... .. 395/187.01
`5,623,601
`5/1997 Land?eld et a1. .................... .. 395/326
`5,632,011
`6/1997 Yu .......... ..
`. 395/500
`5,636,371
`6/1997 Nguyen
`380/29
`5,638,448
`8/1997 Kralowetz
`95/20057
`5,657,452
`9/1997 Falk et a1.
`.... .. 380/25
`5,668,876
`5,687,235 11/1997 Periman et a1.
`.. 380/25
`
`Petitioner Apple Inc. - Ex. 1044, p. 2
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 1 0f 9
`
`5,898,830
`
`CORP.
`
`INTERNET
`
`/
`
`g 3-2 _’ FIREWALL
`
`- w 192.168.X.X§
`
`._ ............................
`
`DNS/DDNS
`
`// //
`
`168
`
`167
`FIREWALL
`DNS/DDNS \\107 "
`
`160
`
`-
`
`-
`
`’
`/
`/ 5.4
`118
`
`109
`
`.
`
`-
`
`\117
`
`155 ’
`\ ’
`;-.__165\ FIREWALL
`/110
`DNS/DDNS
`ADDRESS SUBSET,§ "-._
`I
`
`E.G.192.168.X.X "
`
`101
`/ i
`
`\166
`1_
`i
`'1 152/
`=
`4G-SUBSET ;
`ADDRESSES?
`
`i
`; VIRTUAL HOST
`MACHINE
`
`FIREWALL
`
`1 l6
`\ DNSHDDNS
`\\
`
`105B
`/
`
`105
`/
`
`\115
`
`_
`
`/
`
`'
`
`'
`
`'
`
`<—105A g
`
`4G-SUBSET
`
`102
`
`./1O3
`119
`
`ACCT.
`
`'
`
`;
`5
`
`153
`
`151
`
`Petitioner Apple Inc. - Ex. 1044, p. 3
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 2 0f 9
`
`5,898,830
`
`INTERNET
`
`FIREWALL
`
`DNS/DDNS
`
`220
`
`/207
`/217
`
`209
`
`FIG. 2
`
`Petitioner Apple Inc. - Ex. 1044, p. 4
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 3 0f 9
`
`5,898,830
`
`mom l
`
`<mom
`
`ZOEW<Q AA
`ZOCLEDUEZOU
`
`mwim
`
`am
`
`Em
`
`ZQ
`
`m .UE
`
`rllltm
`
`2m
`
`\
`
`D
`
`
`
`
`
`mmOmMDm - Q<~Ummm
`
`Petitioner Apple Inc. - Ex. 1044, p. 5
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 4 0f 9
`
`5,898,830
`
`INTERNET
`
`420
`
`FIREWALL
`
`FIREWALL
`
`DNS/DDNS — 407
`
`DNS/DDNS _ 408
`
`FIG. 4
`
`Petitioner Apple Inc. - Ex. 1044, p. 6
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 5 of 9
`
`5,898,830
`
`mmemfiz
`
`OEZOO
`
`u5<>>mME
`
`
`
` 04 EHEEmZHEO<§A<UHm>En,_
`
`u_<Dr§:>
`
`~50:
`
`q<DHyd>
`
`N50:
`
`A<DHM:>
`
`ZHmOE
`
`Petitioner Apple Inc. - Ex. 1044, p. 7
`
`Petitioner Apple Inc. - Ex. 1044, p. 7
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 6 0f 9
`
`5,898,830
`
`REQUEST
`
`l / VH1
`
`DAEMON
`
`610
`
`MASTER
`CONFIG
`
`"1111;, EXECUTION THREADS
`
`.. .
`
`/VHN
`PROCESS
`——> OUTPUT
`THIS
`CONNECTION
`
`FIG. 6
`
`Petitioner Apple Inc. - Ex. 1044, p. 8
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 7 0f 9
`
`5,898,830
`
`PORT
`RULEl
`
`:80
`={
`TIME
`
`}
`WWWsRMOcOM
`.CGI
`ROOT
`
`}
`WWW.HONOLULU.NET ={
`:“’7
`
`: “1AM-12PM”
`
`={
`: “PROCESSCGI”
`= “/HOME/SRMC/HTML”
`
`ROOT
`
`}
`WWW.SANJOSE.NET
`.CGI
`ALLOW
`
`}
`DENY
`
`= “fHOME/HONOLULU/HTML”
`
`=
`= “PROCESSCGI”
`:{
`*.sRMc.cOM
`205.138.192.*
`205.138.192.0/23
`
`={
`MISTERPAINCOM
`
`}
`}
`WWPROXYSRMCCOM :{
`MODE
`= RT_SERVERPROXY
`
`}
`NS.SRMC.COM
`ALLOW
`
`}
`}
`MJLIsRMOcOM
`ALLOW
`
`}
`DENY
`
`={
`={
`192.168.0.*
`192.168.1.* =RULE1
`192.168.2.* ={
`TIME
`
`}
`192.168.3.*
`
`=192.168.2.*
`
`: “1AM-12PM”
`
`192.168.0.0/23
`
`= RULEl
`
`= {
`192.168.0.* = {
`TIME
`
`= “12PM-1AM”
`
`FIG. 7
`
`Petitioner Apple Inc. - Ex. 1044, p. 9
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 8 0f 9
`
`5,898,830
`
`MAIN DAEMON / 801
`COMMANDLINE
`PROCESSING
`READ CONFIG 4
`
`61 (k
`MASTER
`CONFIG
`
`WAIT FOR CONNECTION
`REQUEST
`
`VIRTUAL HOST
`810
`/
`
`V
`GET LOCAL
`HOST INFO
`
`v / 803
`MULTI-HOMING
`(WHICH HOST?)
`
`v / s05
`
`
`
`INET “WRAPPER”
`
`GET REMOTE
`HOST INFO
`
`li /818
`CONTENT
`(PROTOCOL BASED)
`PROCESSING
`A
`+___|
`(CLOSE)
`FIG. 8
`
`/820
`CHANNEL
`PROCESSING
`
`v
`
`Petitioner Apple Inc. - Ex. 1044, p. 10
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 9 0f 9
`
`5,898,830
`
`QAAQK/EE
`
`HmZMmCLZH
`
`HWZEHZH
`
`@ .UE
`
`Petitioner Apple Inc. - Ex. 1044, p. 11
`
`

`
`1
`FIREWALL PROVIDING ENHANCED
`NETWORK SECURITY AND USER
`TRANSPARENCY
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`The present invention relates to computer network secu
`rity and more particularly to ?rewalls, i.e., a combination of
`computer hardware and software that selectively allows
`“acceptable” computer transmissions to pass through it and
`disallows other non-acceptable computer transmissions.
`2. State of the Art
`In the space of just a few years, the Internet—because it
`provides access to information, and the ability to publish
`information, in revolutionary ways—has emerged from rela
`tive obscurity to international prominence. Whereas in gen
`eral an internet is a network of networks, the Internet is a
`global collection of interconnected local, mid-level, and
`wide-area networks that use the Internet Protocol (IP) as the
`network layer protocol. Whereas the Internet embraces
`many local- and wide-area networks, a given local- or
`wide-area network may or may not form part of the Internet.
`For purposes of the present speci?cation, a “wide-area
`network”
`is a network that links at least two LANs
`over a wide geographical area via one or more dedicated
`connections. The public switched telephone network is an
`example of a wide-area network. A “local-area network”
`(LAN) is a network that takes advantage of the proximity of
`computers to typically offer relatively ef?cient, higher speed
`communications than wide-area networks.
`In addition, a network may use the same underlying
`technologies as the Internet. Such a network is referred to
`herein as an “Intranet,” an internal network based on Internet
`standards. Because the Internet has become the most per
`vasive and successful open networking standard, basing
`internal networks on the same standard is very attractive
`economically. Corporate Intranets have become a strong
`driving force in the marketplace of network products and
`services.
`The present invention is directed primarily toward the
`connection of an Intranet to the Internet and the connection
`of intranets to other intranets, and any network connection
`where security is an issue.
`As the Internet and its underlying technologies have
`become increasingly familiar, attention has become focused
`on Internet security and computer network security in gen
`eral. With unprecedented access to information has also
`come unprecedented opportunities to gain unauthoriZed
`access to data, change data, destroy data, make unauthoriZed
`use of computer resources, interfere with the intended use of
`computer resources, etc. As experience has shown, the
`frontier of cyberspace has its share of scof?aws, resulting in
`increased efforts to protect the data, resources, and reputa
`tions of those embracing intranets and the Internet.
`Firewalls are intended to shield data and resources from
`the potential ravages of computer network intruders. In
`essence, a ?rewall functions as a mechanism which monitors
`and controls the How of data between two networks. All
`communications, e.g., data packets, which ?ow between the
`networks in either direction must pass through the ?rewall;
`otherwise, security is circumvented. The ?rewall selectively
`permits the communications to pass from one network to the
`other, to provide bidirectional security.
`Ideally, a ?rewall would be able to prevent any and all
`security breaches and attacks. Although absolute security is
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,898,830
`
`2
`indeed a goal to be sought after, due to many variables (e.g.,
`physical intrusion into the physical plant) it may be difficult
`to achieve. However, in many instances, it is of equal if not
`greater importance to be alerted to an attack so that measures
`may be taken to thwart the attack or render it harmless, and
`to avoid future attacks of the same kind. Hence a ?rewall, in
`addition to security, should provide timely information that
`enables attacks to be detected.
`Firewalls have typically relied on some combination of
`two techniques affording network protection: packet ?lter
`ing and proxy services.
`Packet ?ltering is the action a ?rewall takes to selectively
`control the How of data to and from a network. Packet ?lters
`allow or block packets, usually while routing them from one
`network to another (often from the Internet to an internal
`network, and vice versa). To accomplish packet ?ltering, a
`network administrator establishes a set of rules that specify
`what types of packets (e.g., those to or from a particular IP
`address or port) are to be allowed to pass and what types are
`to be blocked. Packet ?ltering may occur in a router, in a
`bridge, or on an individual host computer.
`Packet ?lters are typically con?gured in a “default permit
`stance”; i.e., that which is not expressly prohibited is per
`mitted. In order for a packet ?lter to prohibit potentially
`harmful traf?c, it must know what the constituent packets of
`that traffic look like. However, it is virtually impossible to
`catalogue all the various types of potentially harmful packets
`and to distinguish them from benign packet traffic. The
`?ltering function required to do so is too complex. Hence,
`while most packet ?lters may be effective in dealing with the
`most common types of network security threats, this meth
`odology presents many chinks that an experienced hacker
`may exploit. The level of security afforded by packet
`?ltering, therefore, leaves much to be desired.
`Recently, a further network security technique termed
`“stateful inspection” has emerged. Stateful inspection per
`forms packet ?ltering not on the basis of a single packet, but
`on the basis of some historical window of packets on the
`same port. Although stateful inspection may enhance the
`level of security achievable using packet ?ltering, it is as yet
`relatively unproven. Furthermore, although an historical
`window of packets may enable the ?lter to more accurately
`identify harmful packets, the ?lter must still know what it is
`looking for. Building a ?lter with suf?cient intelligence to
`deal with the almost in?nite variety of possible packets and
`packet sequences is liable to prove an exceedingly difficult
`task.
`The other principal methodology used in present-day
`?rewalls is proxies. In order to describe prior-art proxy
`based ?rewalls, some further de?nitions are required. A
`“node” is an entity that participates in network communi
`cations. A subnetwork is a portion of a network, or a
`physically independent network, that may share network
`addresses with other portions of the network. An interme
`diate system is a node that is connected to more than one
`subnetwork and that has the role of forwarding data from
`one subnetwork to the other (i.e., a “router”).
`Aproxy is a program, running on an intermediate system,
`that deals with servers (e.g., Web servers, FTP servers, etc.)
`on behalf of clients. Clients, e.g. computer applications
`which are attempting to communicate with a network that is
`protected by a ?rewall, send requests for connections to
`proxy-based intermediate systems. Proxy-based intermedi
`ate systems relay approved client requests to target servers
`and relay answers back to clients.
`Proxies require either custom software (i.e., proxy-aware
`applications) or custom user procedures in order to establish
`
`Petitioner Apple Inc. - Ex. 1044, p. 12
`
`

`
`3
`a connection. Using custom software for proxying presents
`several problems. Appropriate custom client software is
`often available only for certain platforms, and the softWare
`available for a particular platform may not be the softWare
`that users prefer. Furthermore, using custom client softWare,
`users must perform extra manual con?guration to direct the
`softWare to contact the proxy on the intermediate system.
`With the custom procedure approach, the user tells the client
`to connect to the proxy and then tells the proxy Which host
`to connect to. Typically, the user Will ?rst enter the name of
`a ?reWall that the user Wishes to connect through. The
`?reWall Will then prompt the user for the name of the remote
`host the user Wishes to connect to. Although this procedure
`is relatively simple in the case of a connection that traverses
`only a single ?reWall, as netWork systems groW in
`complexity, a connection may traverse several ?reWalls.
`Establishing a proxied connection in such a situation starts
`to become a confusing maZe, and a signi?cant burden to the
`user, since the user must knoW the route the connection is to
`take.
`Furthermore, since proxies must typically prompt the user
`or the client softWare for a destination using a speci?c
`protocol, they are protocol-speci?c. Separate proxies are
`therefore required for each protocol that is to be used.
`Another problematic aspect of conventional ?reWall
`arrangements, from a security perspective, is the common
`practice of combining a ?reWall With other packages on the
`same computing system. The ?reWall package itself may be
`a combination of applications. For example, one Well-knoWn
`?reWall is a combination Web server and ?reWall. In other
`cases, unrelated services may be hosted on the same com
`puting platform used for the ?reWall. Such services may
`include e-mail, Web servers, databases, etc. The provision of
`applications in addition to the ?reWall on a computing
`system provides a path through Which a hacker can poten
`tially get around the security provided by the ?reWall.
`Combining other applications on the same machine as a
`?reWall also has the result of alloWing a greater number of
`users access to the machine. The likelihood then increases
`that a user Will, deliberately or inadvertently, cause a secu
`rity breach.
`There remains a need for a ?reWall that achieves both
`maximum security and maximum user convenience, such
`that the steps required to establish a connection are trans
`parent to the user. The present invention addresses this need.
`
`SUMMARY OF THE INVENTION
`The present invention, generally speaking, provides a
`?reWall that achieves maximum netWork security and maxi
`mum user convenience. The ?reWall employs “envoys” that
`exhibit the security robustness of prior-art proxies and the
`transparency and ease-of-use of prior-art packet ?lters, com
`bining the best of both Worlds. No traf?c can pass through
`the ?reWall unless the ?reWall has established an envoy for
`that traf?c. Both connection-oriented (e.g., TCP) and con
`nectionless (e.g., UDP-based) services may be handled
`using envoys. Establishment of an envoy may be subjected
`to a myriad of tests to “qualify” the user, the requested
`communication, or both. Therefore, a high level of security
`may be achieved.
`Security may be further enhanced using out-of-band
`authentication. In this approach, a communication channel,
`or medium, other than the one over Which the netWork
`communication is to take place, is used to transmit or convey
`an access key. The key may be transmitted from a remote
`location (e.g, using a pager or other transmission device) or
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,898,830
`
`4
`may be conveyed locally using a hardWare token, for
`example. To gain access, a hacker must have access to a
`device (e.g., a pager, a token etc.) used to receive the
`out-of-band information. Pager beep-back or similar authen
`tication techniques may be especially advantageous in that,
`if a hacker attempts unauthoriZed access to a machine While
`the authoriZed user is n possession of the device, the user
`Will be alerted by the device unexpectedly receiving the
`access key. The key is unique to each transmission, such that
`even if a hacker is able to obtain it, it cannot be used at other
`times or places or With respect to any other connection.
`Using envoys, the added burden associated With prior-art
`proxy systems is avoided so as to achieve full transparency
`the user can use standard applications and need not even
`knoW of the existence of the ?reWall. To achieve full
`transparency, the ?reWall is con?gured as tWo sets of virtual
`hosts. The ?reWall is, therefore, “multi-homed,” each home
`being independently con?gurable. One set of hosts responds
`to addresses on a ?rst netWork interface of the ?reWall.
`Another set of hosts responds to addresses on a second
`netWork interface of the ?reWall. In accordance With one
`aspect of the invention, programmable transparency is
`achieved by establishing DNS mappings betWeen remote
`hosts to be accessed through one of the netWork interfaces
`and respective virtual hosts on that interface. In accordance
`With another aspect of the invention, automatic transparency
`may be achieved using code for dynamically mapping
`remote hosts to virtual hosts in accordance With a technique
`referred to herein as dynamic DNS, or DDNS.
`The ?reWall may have more than tWo netWork interfaces,
`each With its oWn set of virtual hosts. Multiple ?reWalls may
`be used to isolate multiple netWork layers. The full trans
`parency attribute of a single ?reWall system remains
`unchanged in a multi-layered system: a user may, if
`authoriZed, access a remote host multiple netWork layers
`removed, Without knoWing of the existence of any of the
`multiple ?reWalls in the system.
`Furthermore, the ?reWalls may be con?gured to also
`transparently perform any of various kinds of channel
`processing, including various types of encryption and
`decryption, compression and decompression, etc. In this
`Way, virtual private netWorks may be established Whereby
`tWo remote machines communicate securely, regardless of
`the degree of proximity or separation, in the same manner as
`if the machines Were on the same local area netWork.
`The problem of Internet address scarcity may also be
`addressed using multi-layer netWork systems of the type
`described. Whereas addresses on both sides of a single
`?reWall must be unique in order to avoid routing errors,
`netWork segments separated by multiple ?reWalls may reuse
`the same addresses.
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`The present invention may be further understood from the
`folloWing description in conjunction With the appended
`draWing. In the draWing:
`FIG. 1 is a block diagram of a multi-layered computer
`enterprise netWork in Which the present invention may be
`used;
`FIG. 2 is a block diagram of a netWork similar to the
`netWork of FIG. 1 but in Which a tWo-sided ?reWall has been
`replaced by a three-sided ?reWall;
`FIG. 3 is a block diagram shoWing in greater detail a
`special-purpose virtual host used for con?guration of a
`?reWall;
`
`Petitioner Apple Inc. - Ex. 1044, p. 13
`
`

`
`5,898,830
`
`5
`FIG. 4 is a block diagram of a load-sharing ?rewall;
`
`FIG. 5 is a block diagram of one embodiment of the
`?rewall of the present invention;
`
`6
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`FIG. 6 is a block diagram illustrating the manner in which
`the present ?rewall handles connection requests;
`
`The following terms are used in the present speci?cation
`in accordance with the following de?nitions:
`
`Concept/Feature
`
`Multi-homing
`
`Programmable transparency
`
`Envoy
`
`Multi-layering
`
`Con?gurator
`
`N-dimensional ?rewall
`
`Out-of-band authentication
`
`Channel processing
`
`virtual private network
`
`DDNS
`
`Load sharing
`
`Address reuse
`
`Programmable
`transparency—connectionless protocols
`
`De?nition
`
`Multiple virtual hosts running on a
`single physical machine, using multiple
`network addresses on a single network
`interface. A virtual host assumes the
`identity of one of multipe,
`independently-con?gurable “homes” to
`handle a particular connection at a
`particular time.
`The ability to establish a connection
`through a ?rewall without requiring
`that the user be aware of the ?rewall.
`An intervening program that functions
`as a transparent applications gateway.
`The use of programmable transparency
`to achieve end-to-end connection
`across an arbitrary number of networks
`that are connected by multiple multi
`homing ?rewalls.
`Code that provides a Web-like
`interface, accessible remotely through
`a secure port, for con?guring a
`?rewall.
`A ?rewall having N network interfaces
`and con?gured to provide multiple
`virtual hosts for each interface.
`In deciding whether to allow or
`disallow a connection by a user, the
`use of information communicated to
`the user through means other than the
`desired connection.
`Processing performed on data flowing
`through a communications channel to
`enhance some attribute of the data,
`such as security, reproduction quality,
`content, etc.
`An internet in which envoys
`(intervening programs) are used to
`perform encrypted communications
`from one secure network to another
`through a none-secure network.
`The dynamic assignment of network
`addresses to virtual hosts on a time
`limited basis.
`The use of DDNS to assign a network
`address for a particular connection to a
`virtual host on one of multiple
`machines based on the load of the
`machines.
`The use of the same network address
`within different networks separated by
`?rewalls.
`The use of envoys for connectionless
`(e.g., UDP) communications in which a
`time-out value is used to achieve the
`equivalent of a connection.
`
`FIG. 7 is an eXample of a portion of the master con?gu
`ration ?le of FIG. 5;
`
`FIG. 8 is a block diagram illustrating in greater detail the
`structure of the present ?rewall; and
`
`FIG. 9 is a block diagram of a combination ?rewall that
`allows the bulk of the entire Internet address space to be
`used on both sides of the ?rewall.
`
`65
`
`The present ?rewall provides a choke point used to
`control the How of data between two networks. One of the
`two networks may be the Internet, or both of the two
`networks may be intranets-the nature and identity of the two
`networks is immaterial. The important point is that all traf?c
`between the two networks must pass through a single,
`narrow point of controlled access. A?rewall therefore brings
`a great deal of leverage to bear on the problem of network
`security, allowing security measures to be concentrated on
`
`Petitioner Apple Inc. - Ex. 1044, p. 14
`
`

`
`7
`this controlled access point. To avoid possible security
`compromises, the ?rewall should ideally run on a dedicated
`computer, i.e. one Which does not have any other user
`accessible programs running on it that could provide a path
`via Which communications could circumvent the ?reWall.
`One environment in Which ?reWalls are particularly desir
`able is in enterprise netWork systems, in Which a number of
`individual netWorks that may be respectively associated With
`different departments or divisions of a company, for
`example, are connected With one another. In such an
`environment, ?reWalls can be employed to restrict access to
`the individual netWorks. While not limited to this particular
`situation, the present invention Will be, described hereinafter
`in such a context, to facilitate an understanding of its
`underlying principles.
`Referring noW to FIG. 1, assume that the accounting
`departments of tWo remote corporate sites are networked,
`and that these tWo different accounting netWorks are to be
`connected via the Internet or a similar non-secure, Wide-area
`netWork. For purposes of illustration, a ?rst site 101 having
`a ?rst accounting netWork 103 might be located in
`California, and a second site 151 having a second accounting
`netWork 153 might be located in Japan. Within each site,
`each accounting netWork may be part of a larger corporate
`netWork (109, 159). Precautions are required to safeguard
`sensitive accounting data such that it cannot be accessed
`over the general corporate netWork. A ?rst ?reWall (105,
`155) is used for this purpose. The ?rst ?reWall is interposed
`betWeen the accounting netWork and the general corporate
`netWork.
`A convenient Way to place the tWo accounting netWorks
`in communication With each other is through the Internet
`120, Which comprises another layer of a multi-layer net
`Work. As compared to other forms of connection, the Inter
`net may be more economical, more easily accessible, and
`more robust. Connecting to the Internet, hoWever, requires
`that access betWeen the Internet and the respective sites be
`strictly controlled. A second ?reWall (107, 157) is used at
`each site for this purpose.
`In the folloWing description, the present ?reWall is illus
`trated most often as a rectangle having along each of tWo
`edges thereof a netWork connection and a roW of boxes
`representing multiple “homes,” corresponding to respective
`virtual hosts. A virtal host along one edge may be used to
`initiate a connection only in response to a request from the
`netWork connection that enters the ?reWall at that edge. The
`connection, once established, is fully bi-directional, With the
`same virtual host passing data betWeen the originating
`netWork connection and the netWork connection at the
`opposite edge of the ?reWall.
`More generally, the ?reWall may be N-sided, having N
`netWork connections and being illustrated as an N-sided
`polygon. Any virtual host may establish a connection
`betWeen any pair of netWork connections so long as the
`connection originated from the netWork connection adjoin
`ing that virtual host. Again, the connection, once established,
`is fully bidirectional.
`The ?reWalls 105, 107, 155 and 157 are each of a
`construction to be more particularly described hereinafter.
`Each ?reWall is multi-homing. This means that each ?reWall
`is con?gured as multiple virtual hosts running on a physical
`computer. In the example of FIG. 1, a ?reWall is depicted as
`a single computer having multiple virtual hosts on each of its
`tWo interfaces. In practice, the multiple virtual hosts can be
`con?gured in this manner or, alternatively, implemented in
`any number of computers, as explained in detail hereinafter.
`
`55
`
`65
`
`15
`
`35
`
`45
`
`5,898,830
`
`8
`Each virtual host corresponds to a “home”, i.e. a site via
`Which a connection is made betWeen the tWo netWorks on
`either side of the ?reWall. At different times, the same virtual
`host might correspond to different homes associated With
`different connections. At any given time, hoWever, a virtual
`host represents one home. In the folloWing description of the
`particular example illustrated in FIG. 1, therefore, homes
`and virtual hosts are described as being synonymous With
`one another. Each virtual host is fully independently con
`?gurable and unique from each of the other virtual hosts.
`Considering the ?reWall 105 as being exemplary of each of
`the ?reWalls 105, 107, 155 and 157, one set of hosts 105a
`responds to addresses on a ?rst netWork interface of the
`?reWall. Another set of hosts 105b responds to addresses on
`a second netWork interface of the ?reWall.
`Normally, in accordance With the prior art, connecting
`from one computer to another remote computer along a
`route traversing one or more ?reWalls Would require the user
`to con?gure a prior-art proxy for each ?reWall to be tra
`versed. In accordance With one aspect of the invention,
`hoWever, programmable transparency is achieved by estab
`lishing DNS mappings betWeen remote hosts to be accessed
`through one of the netWork interfaces and respective virtual
`hosts on that interface.
`DNS is a distributed database system that translates host
`names to IP addresses and IP addresses to host names (e.g,
`it might translate host name omer.odyssey.com to
`129.186.424.43). The information required to perform such
`translations is stored in DNS tables. Any program that uses
`host names can be a DNS client. DNS is designed to
`translate and forWard queries and responses betWeen clients
`and servers.
`When a client needs a particular piece of information
`(e.g., the IP address of homer.odyssey.com), it asks its local
`DNS server for that information. The local DNS server ?rst
`examines its oWn local memory, such as a cache, to see if it
`already knoWs the ansWer to the client’s query. If not, the
`local DNS server asks other DNS servers, in turn, to
`discover the ansWer to the client’s query. When the local
`DNS server gets the ansWer (or decides that for some reason
`it cannot), it stores any information it received and ansWers
`the client. For example, to ?nd the IP address for
`homer.odyssey.com, the local DNS server ?rst asks a public
`root name server Which machines are name servers for the
`corn domain. It then asks one of those “com” name servers
`Which machines are name servers for the odyssey.com
`domain, and then it asks one of those name servers for the
`IP address of homer.odyssey.com.
`This asking and ansWering is all transparent to the client.
`As far as the client is concerned, it has communicated only
`With the local s

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket