Atty. Docket No.: FORT-020300 (cid:9)
`15101
`Fortinet Ref. No.: (cid:9)
`
`Provisional Application
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`TITLE OF THE INVENTION
`
`BUILDING A COOPERATIVE SECURITY FABRIC OF HIERARCHICALLY
`INTERCONNECTED NETWORK SECURITY DEVICES
`
`Inventors:
`
`MICHAEL XIE, residing at:
`685 Loma Verde Avenue
`Palo Alto, CA 94306
`
`ROBERT A. MAY, residing at:
`1406 Dempsey Rd.
`North Vancouver, BC V7K 1S6
`CANADA
`
`YON G WANG
`Mailing address:
`4190 Still Creek Drive, Suite 400
`Burnaby, BC V5C 6C6
`CANADA
`
`JORDAN THOMPSON
`Mailing address:
`4190 Still Creek Drive, Suite 400
`Burnaby, BC V5C 6C6
`CANADA
`
`LINO XU
`Mailing address:
`4190 Still Creek Drive, Suite 400
`Burnaby, BC V5C 6C6
`CANADA
`
`SHENCHE WANG
`Mailing address:
`4190 Still Creek Drive, Suite 400
`Burnaby, BC V5C 6C6
`CANADA
`
`Assignee: (cid:9)
`
`FORTINET, INC.
`A Delaware Corporation
`
`Entity: (cid:9)
`
`Regular Undiscounted
`
`1
`
`Fortinet Ex. 2016, Page 1 of 87
`
`

`

`BUILDING A COOPERATIVE SECURITY FABRIC OF HIERARCHICALLY
`INTERCONNECTED NETWORK SECURITY DEVICES
`
`COPYRIGHT NOTICE
`
`[0001] (cid:9)
`
`Contained herein is material that is subject to copyright protection. The
`copyright owner has no objection to the facsimile reproduction of the patent disclosure by
`any person as it appears in the Patent and Trademark Office patent files or records, but
`otherwise reserves all rights to the copyright whatsoever. Copyright © 2017, Fortinet, Inc.
`
`Field
`
`BACKGROUND
`
`[0002] (cid:9)
`Embodiments of the present invention generally relate to network security
`devices and network management devices. In particular, embodiments of the present
`invention relate to systems and methods for construction, management and use of a
`cooperative security fabric formed by hierarchically interconnected network security devices
`deployed within a protected network.
`
`Description of the Related Art
`
`[0003] (cid:9)
`A typical enterprise or data center network includes, among other network
`devices and servers, multiple network security devices implementing various security-related
`functions, including, but not limited to, intrusion detection, intrusion prevention, content
`filtering, anti -m al ware, anti sp am , Virtual Private Networking (VPN) capabilities, network
`traffic/event logging, identity-based access control, Data Leak Prevention (DLP), load
`balancing, Quality of Service (QoS), SSL/SSH inspection and application control.
`
`[0004] (cid:9)
`While security management appliances, such as the FortiManager® security
`management appliance (available from Fortinet, Inc. of Sunnyvale, CA), exist that allow a
`network administrator to configure, provision and/or manage a large number of network
`security devices, global resource optimizations relating to firewall policy optimization and/or
`logging optimization, for example, require full information regarding the network topology,
`including the interconnections (e.g., upstream and downstream relationships) among the
`managed network security devices.
`
`2
`
`Fortinet Ex. 2016, Page 2 of 87
`
`

`

`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0005] (cid:9)
`
`In the Figures, similar components and/or features may have the same reference
`
`label. Further, various components of the same type may be distinguished by following the
`
`reference label with a second label that distinguishes among the similar components. If only
`
`the first reference label is used in the specification, the description is applicable to any one of
`
`the similar components having the same first reference label irrespective of the second
`
`reference label.
`
`[0006] (cid:9)
`
`FIG. 1 illustrates an exemplary cooperative security fabric (CSF) created in
`
`accordance with an embodiment of the present invention.
`
`[0007] (cid:9)
`
`FIG. 2 illustrates exemplary functional modules of a network security device for
`
`dynamically forming a cooperative security fabric in accordance with an embodiment of the
`
`present invention.
`
`[0008] (cid:9)
`
`FIG. 3 is a flow diagram illustrating query handling by a network security
`
`device (NSD) in accordance with an embodiment of the present invention.
`
`[0009] (cid:9)
`
`FIG. 4 is a flow diagram illustrating a downstream view of tunnel creation
`
`between two network security devices (NSDs) by a backend daemon in accordance with an
`
`embodiment of the present invention.
`
`[00010] (cid:9)
`
`FIG. 5 is a flow diagram illustrating an upstream view of tunnel creation
`
`between two NSDs in accordance with an embodiment of the present invention.
`
`[00011] (cid:9)
`
`FIG. 6 illustrates a visual representation of NSDs associated with a private
`
`network arranged as a CSF in accordance with an embodiment of the present invention.
`
`[00012] (cid:9)
`
`FIG. 7 illustrates an exemplary computer system in which or with which
`
`embodiments of the present invention may be utilized.
`
`3
`
`Fortinet Ex. 2016, Page 3 of 87
`
`

`

`DETAILED DESCRIPTION
`
`[00013] (cid:9)
`
`Systems and methods are described for a cooperative security fabric (CSF)
`protocol that facilitates the dynamic formation of a CSF among multiple network security
`devices within a private network based on hierarchical interconnections among the network
`security devices. Embodiments of the present disclosure include various steps, which will be
`described below. The steps may be performed by hardware components or may be embodied
`in machine-executable instructions, which may be used to cause a general-purpose or special-
`purpose processor programmed with the instructions to perform the steps. Alternatively, steps
`may be performed by a combination of hardware, software, firmware and/or by human
`operators.
`
`[00014] (cid:9)
`
`Embodiments of the present disclosure may be provided as a computer program
`product, which may include a machine-readable storage medium tangibly embodying thereon
`instructions, which may be used to program a computer (or other electronic devices) to
`perform a process. The machine-readable medium may include, but is not limited to, fixed
`(hard) drives, magnetic tape, floppy diskettes, optical disks, compact disc read-only
`memories (CD-ROMs), and magneto-optical disks, semiconductor memories, such as ROMs,
`PROMs, random access memories (RAMs), programmable read-only memories (PROMs),
`erasable PROMs (EPROMs), electrically erasable PROMs (EEPROMs), flash memory,
`magnetic or optical cards, or other type of media/machine-readable medium suitable for
`storing electronic instructions (e.g., computer programming code, such as software or
`firmware).
`
`[00015] (cid:9)
`
`Various methods described herein may be practiced by combining one or more
`machine-readable storage media containing the code according to the present disclosure with
`appropriate standard computer hardware to execute the code contained therein. An apparatus
`for practicing various embodiments of the present disclosure may involve one or more
`computers (or one or more processors within a single computer) and storage systems
`containing or having network access to computer program(s) coded in accordance with
`various methods described herein, and the method steps of the disclosure could be
`accomplished by modules, routines, subroutines, or subparts of a computer program product.
`
`[00016] (cid:9)
`
`If the specification states a component or feature "may", "can", "could", or
`"might" be included or have a characteristic, that particular component or feature is not
`required to be included or have the characteristic.
`
`4
`
`Fortinet Ex. 2016, Page 4 of 87
`
`

`

`[00017] (cid:9)
`
`Systems and methods are described for dynamically forming a cooperative
`security fabric (C SF) based on hierarchical interconnections among network security devices
`within a network. Systems and methods are disclosed for network security devices to form a
`cooperative security fabric (C SF), which can be used to obtain desired information regarding
`network topology and to efficiently devise and implement resource optimizations for
`participating network security devices.
`
`[00018] (cid:9)
`
`In an aspect, the present disclosure relates to a system comprising a cooperative
`security fabric (CSF) construction module configured to dynamically construct a CSF based
`on hierarchical interconnections among multiple network security devices deployed within a
`protected network by determining a relative position of each of the network security devices
`within the CSF based on an identifier associated with the respective network security devices,
`wherein each node of the CSF represents a network security device of the multiple network
`security devices and each node of the C SF, except a root node of the C SF and leaf nodes of
`the CSF, has one parent node and one or more child nodes. In one embodiment, the CSF
`protocol limits issuance of a query by an originating node to a downstream node (i.e., a child
`node or a lower level node in the hierarchy of the CSF that is connected to a child node). In
`such an embodiment, a downstream node would not be permitted to query an upstream node
`(e.g., a parent node or a higher level node in the hierarchy of the CSF) or a node at the same
`hierarchical level within the CSF.
`
`[00019] (cid:9)
`
`The system of the present disclosure further includes a tunnel based
`communication module configured to enable communication of periodic keep-alive messages
`and on-demand query messages among parent nodes and their respective child nodes by
`establishing, using a backend daemon running on the network security devices, a tunnel
`between the parent nodes and each of their child nodes, if any.
`
`In an aspect, the network security devices can be selected from one or a
`[00020] (cid:9)
`combination of gateway devices, firewall devices, Intrusion Detection Systems (IDSs),
`Intrusion Prevention Systems (IPSs), and Unified Threat Management (UTM) devices. In one
`embodiment, each network security device of the multiple network security devices
`participating in the CSF is aware of only those of the network security devices that are
`directly connected to it, including its parent and its children.
`
`[00021] (cid:9)
`
`In another aspect, only the root node network security device is aware of the
`complete topology of the CSF by means of one of its local daemons. The system of the
`present disclosure can further be configured to enable a particular network security device to
`
`- 5 -
`
`Fortinet Ex. 2016, Page 5 of 87
`
`

`

`issue a query to a downstream destination network security device using the forward daemon.
`
`In embodiments of the present invention queries may be used to, among other things, gather
`
`topology information regarding the subtrees of downstream nodes, gather information
`
`regarding the identity (e.g., IP address, MAC address and/or serial number) of each
`
`downstream NSD, including its type, functionality, capabilities, configuration, status,
`
`performance, resources and tunnel/virtual links.
`
`[00022] (cid:9)
`
`In one embodiment, queries include a whole path and query data, wherein the
`
`whole path can include at least one unique attribute (e.g., IP address, MAC address and/or
`
`serial number) of each intermediate network security device between the particular network
`
`security device and the downstream destination network security device that the query should
`
`pass through. When the query is received at the downstream destination network security
`
`device, the query data can be processed by the downstream destination network security
`
`device to obtain a response that is proxied back to the particular network security device.
`
`[00023] (cid:9)
`
`In an aspect, the tunnel established between each parent network security device
`
`and child network security device is bidirectional, thereby allowing for communication of
`
`downstream query messages, upstream responses, keep-alive messages and corresponding
`
`responses through the same tunnel. In yet another aspect, a network security device can
`
`perform resource optimization for its downstream network security devices. In yet another
`
`aspect, a new network security device intending to join the CSF can provide authentication
`
`information along with an identifier of its parent network security device, and wherein upon
`
`successful authentication of the new network security device, the new network security
`
`device is made part of the CSF and added below the parent network security device. On the
`
`other hand, when a child network security device leaves CSF 100, the child network security
`
`device may simply close the connection or disconnect directly to enable the parent NSD to
`
`remove the child NSD based on a timer.
`
`[00024] (cid:9)
`
`Those skilled in the art will appreciate that the proposed system does not require
`
`election of a master network security device for performing optimization and other network
`
`security/management functions as the root node network security device (i.e., the network
`
`security device within the CSF that does not have a parent node) can be recognized as the
`
`master network security device by default. The system can further enable the root network
`
`security device to be fully aware of the entire network topology, and each network security
`
`device can be aware of the topology of downstream network security devices attached
`
`thereto, enabling any particular network security device to perform resource optimization for
`
`6
`
`Fortinet Ex. 2016, Page 6 of 87
`
`

`

`downstream network security devices. In alternative embodiments, each NSD participating
`in CSF 100 may be provided with full information regarding CSF 100 and the NSDs may
`perform an election process to select a master NSD.
`
`[00025] (cid:9)
`FIG. 1 illustrates an exemplary cooperative security fabric (CSF) 100 created in
`accordance with an embodiment of the present invention. In the simplified example
`illustrated by FIG. 1, CSF 100 includes one root node network security device (NSD), which
`may also be referred to interchangeably as the master network security device or root node,
`multiple intermediate node NSDs (i.e., NSD 2 104a, NSD 4 104c, NSD 7 104f, and NSD 9)
`104h, and multiple leaf node NSDs (i.e., NSD 3 104b, NSD 5 104d, NSD 6 104e, NSD 8
`104q, and NSD 10 104i). Each intermediate node NDS of CSF 100 may be aware of
`downstream network topology, along with being aware of its connected downstream network
`security devices, and its parent node. For instance, NSD 102 would be aware of the entire
`network topology, whereas NSD 2 104a would only be aware of its downstream nodes - NSD
`5 104d and NDS 6 104e — and its parent, NDS 1 102.
`
`[00026] (cid:9)
`According to one emboidment CSF 100 can be dynamically constructed and
`maintained in a recursive way based on the downstream-upstream relationships defined by
`the hierarchical interconnection of the network security devices within the private network.
`For example, NSD 1 102, having no parent, may initially represent a CSF containing only
`one member. The other NSDs 104a-i, having one or more upstream NSDs, may join the CSF
`to which its parent belongs as described further below. Once CSF 100 stabilizes, the root
`node, i.e., NSD 1 102, has full information regarding CSF 100.
`
`[00027] (cid:9)
`As noted above, NSDs participating within CSF 100 are permitted to issue
`queries to downstream NSDs participating within CSF 100. As such, NSD 2 104a may issue
`a query to either or both of NSD 5 104d and NSD 6 104e. In one embodiment, however, the
`CSF protocol precludes participating NSDs from issuing queries to upstream NSDs or NSDs
`that are not downstream from the NSD at issue. For example, in an embodiment in which
`such limitations are enforced by the CSF protocol, NSD 2 104a would not be permitted to
`issue a query to any of NSD 1 102, NSD 3 104b, NSD 4 104c, NSD 7 104f, NSD 8 104g,
`NSD 9 104h and NSD 10 104i.
`
`[00028] (cid:9)
`As shown in FIG. 1, network security device 1 102, being the root note of the
`CSF 100, does not have a parent node and can be recognized as the master network security
`device within CSF 100. Nodes within CSF 100 can distinguish between being a leaf node
`and a root node in a number of ways, including whether they are directly coupled to more
`
`7
`
`Fortinet Ex. 2016, Page 7 of 87
`
`

`

`than one other node and whether they have a direct WAN connection. In addition to the
`permissible actions allowed to be performed by upstream network security devices (e.g.,
`performing resource optimization for a downstream network security device and/or
`management of a downstream network security device), the master network security device
`has knowledge of the entire topology of the private network (not shown) within which CSF
`100 is formed.
`
`[00029] (cid:9)
`
`In an exemplary implementation, CSF 100 can be built in such a manner that
`each node of CSF 100 can request information regarding its downstream nodes and can send
`a query that may include an address of the destination node, a path to be followed from the
`source node (i.e., the node from which the query is originated) to the destination node, and
`query data. As those skilled in the art will appreciate, by making CSF 100, the root node,
`NSD 102, in the present example, becomes the master NSD and the other nodes in CSF 100
`are fully aware of their respective downstream NSDs connected with them as well as their
`respective parent nodes. Each intermediate node NSD of the NST 100 may be aware of its
`parent NSD and child NSD(s). In the context of the present example, NSD 7 104 would be
`aware of its parent NSD 4 104c, and of its children NSD 8 104g and NSD 9 104h. In CSF
`100, each node, except the root node NSD 102 and leaf nodes (i.e., NSDs 104d, 104e, 104b,
`104g, and 104i), has one upstream node and one or more downstream nodes/NSDs. For
`instance, from the perspective of NSD 104a, NSD 102 represents an upstream node, and 104d
`and 104e represent downstream NSD nodes.
`
`[00030] (cid:9)
`
`Each node of CSF 100 can be configured to be only aware of the nodes/NSDs
`directly connected with it. As those skilled in the art will appreciate, CSF 100 made in
`accordance with an embodiment of the present invention does not require election of a master
`NSD as the nodes/NSDs within CSF 100 that have a parent/upstream device recognize they
`are not the head/root/master of CSF 100 and the one node/NSD within CSF 100 that does not
`have a parent/upstream device recognizes itself as the head/root/master of CSF 100.
`
`In an exemplary implementation, each node of CSF 100 may include one or
`[00031] (cid:9)
`more daemons, including a backend daemon and a forward daemon. In an exemplary
`implementation, the backend daemon running within a particular NSD can establish/create
`bidirectional tunnels between (i) the particular NSD and its parent, if any; and (ii) the
`particular NSD and each of its child nodes, if any. Further details regarding tunnel creation
`are described below with reference to FIG. 4. Each bidirectional tunnel can be configured to
`allow an upstream node/NSD to query a downstream node/NSD that it is connected to
`
`8
`
`Fortinet Ex. 2016, Page 8 of 87
`
`

`

`through the tunnel. Such a tunnel, in one exemplary configuration, can restrict the
`downstream node/NSD from sending queries to its upstream node/NSD. In general, when an
`upstream NSD queries a downstream NSD, the query is passed from the forward daemon of
`the upstream NSD (which may be referred to herein as an "uplevel daemon") to the backend
`daemon of an intermediate NSD, if any, (which may be referred to herein as a "downlevel
`daemon") and ultimately to the destination NSD. When the query reaches the destination
`NDS, the query is processed by the local backend daemon of the destination NSD. In this
`manner, queries may propagate downward toward the destination NSD in a recursive manner
`passing through the various intermediate uplevel and downlevel daemons as described further
`below. Similarly, responses to queries may propagate upward toward the originating NSD in
`a recursive manner passing through various intermediate downlevel and uplevel daemons.
`
`[00032] (cid:9)
`For purposes of illustration, when node 104c queries node 104h, a first tunnel
`that has been created between node 104c and node 104f is initially used to pass the query
`from the forward daemon of node 104c to the backend daemon of node 104f. Then, the
`query is further passed from the forward daemon of NSD 104f to the backend daemon of
`NSD 104h via the tunnel established between NSD 104f and NSD 104h. Finally, at the
`destination (i.e., node 104f), the query is handled by local backend daemon.
`
`[00033] (cid:9)
`In alternative embodiments, the communication channel between directly
`connected NSD can be implemented as two separate unidirectional tunnels, one for issuing
`commands, queries and/or keep-alive messages from an upstream node to a downstream node
`and one for returning responses to such commands, queries and/or keep-alive messages.
`Furthermore, while in the examples described herein, queries are described as flowing in a
`downstream direction, in some embodiments, downstream nodes may be allowed to query or
`update upstream nodes in one or more defined circumstances. For example, in one
`embodiment, responsive to accepting a join request from a new NSD, the NSD that has
`integrated the new NSD into its subtree may provide a topology update regarding its subtree
`to its parent via the tunnel connecting the two. In one embodiment, this topology update may
`be propagated all the way to the root of CSF 100.
`
`[00034] (cid:9)
`In an exemplary implementation, the backend daemon running within each node
`of CSF 100 can be configured to create a tunnel or virtual link, for example, tunnel 106,
`between the upstream and downstream devices and handle one or more exceptions, if any.
`Backend daemon may also provide an Application Programming Interface (API), for example
`a Representational State Transfer (REST) or RESTful API, to the uplevel daemon to enable
`
`9
`
`Fortinet Ex. 2016, Page 9 of 87
`
`

`

`queries to be received and processed by the backend daemon. In an exemplary
`implementation, each node of CSF 100 may have a forward daemon that is configured to
`enable query initiation and response processing. The forward daemon can initiate a query,
`which may include a destination address, a complete path from the source node to the
`destination node, for example, indicating the addresses of all intermediate nodes through
`which the query is to pass, and query data. As described in further detail with reference to
`FIG. 3, each intermediate node, upon receiving a query, identifies whether the query is
`destined to it and, if so, can accordingly process the query; otherwise, the intermediate node
`can forward the query towards the destination node based on the path defined in the query.
`
`[00035] (cid:9)
`The bidirectional tunnels represented by the connections between the nodes in
`CSF 100 may be established during construction of CSF 100. Alternatively, they may be
`established on demand. In an exemplary implementation, when a query is initiated by an
`uplevel daemon, the backend daemon of the source NSD can create the required tunnel
`between the source NSD and the next NSD, and similarly subsequent required tunnels can be
`created by other intermediate NSD(s) between themselves and their direct downstream NSD.
`When a query arrives at the destination node, backend daemon of the destination node can
`send the query by making an appropriate call via the local RESTful API and wait for the
`response. The destination NSD can then generate a response, which can be proxied back to
`each upstream device until it reaches the source NSD. As those skilled in the art will
`appreciate, no path is required for a response as each node of CSF 100 can only have one
`parent. As such, a response can simply be propagated upstream until it reaches the source
`NSD that issued the corresponding query. An exemplary set of REST APIs is described in
`the attached Appendix.
`
`[00036] (cid:9)
`
`In an exemplary implementation, for a given tree such as CSF 100, a group
`name and password associated with CSF 100 can be used to allow a new NSD to join CSF
`100 and authenticate itself to its parent. In order to join CSF 100, a new NSD may send a join
`request, including the group name and password to the Internet Protocol (IP) address of its
`parent. Responsive to receipt of the join request, the parent NSD verifies the group name and
`password, and upon successful verification, the backend daemon of the parent NSD may
`establish a bidirectional tunnel with the new NSD and update the subtree rooted at itself to
`include the new NSD. As described further below, the tunnel is used for periodic keep-alive
`messages between parent and child and for on-demand query messages from parent to child.
`
`- 10 -
`
`Fortinet Ex. 2016, Page 10 of 87
`
`

`

`[00037] (cid:9)
`In one embodiment, rather than reporting a topology change upward through
`CSF 100 responsive to acceptance of a join request, upstream NSDs can request topology
`information associated with the subtree of a downstream NSD on demand, for example,
`responsive to a network administrator requesting a refresh of a graphical user interface
`presented by the root NSD. For instance, with respect to FIG. 1, a new NSD (not shown) can
`send a join request to become a part of CSF 100 to NSD 104b, which upon, authentication
`and verification, can add the new NSD as its child node. At a later time, responsive to a
`query by NSD 1 102 requesting topology information, NSD 3 104b can provide topology
`information regarding its subtree. Alternatively, information about integration of a new NSD
`can be passed up to a root node NSD, which can then broadcast the information to other
`NSDs participating in CSF 100.
`
`[00038] (cid:9)
`In an exemplary implementation, root node NSD, for example NSD 102 of NST
`100, can information regarding the entire topology of CSF 100 by sending a query requesting
`topology information regarding the subtrees of each of its children. Upstream NSDs can be
`aware of the identity of each NSD, its type, capabilities, resources etc. and tunnel/virtual
`links. Identity of each NSD, its type, capabilities, resources etc. and the tunnel/virtual links
`created between the NSDs can be transparent.
`[00039] (cid:9)
`FIG. 2 illustrates exemplary functional modules of a network security device
`(NSD) 200 for dynamically forming a C SF in accordance with an embodiment of the present
`invention. In this simplified example, NSD 200 may include a CSF construction module 202
`and a tunnel based communication module 204, which together can be used by NSD 200 be
`used for dynamically forming a CSF (e.g., CSF 100) that can enable each NSD forming part
`of the CSF to be aware of the network topology of its downstream devices and enable
`resource optimization (e.g., firewall policy optimization and/or logging optimization) of
`downstream NSDs. Depending upon the particular implementation, NSD 200 may represent
`a gateway device, a firewall device, an Intrusion Detection System (IDS), an Intrusion
`Prevention Systems (IP S ) and/or a Unified Threat Management (UTM) device.
`[00040] (cid:9)
`Collectively, CSF construction module 202 of each of the NSDs within a private
`network dynamically constructs a CSF based on the hierarchical interconnections among
`them by determining its relative position as a root, intermediate or leaf node. As noted
`above, NSDs may send join requests to their parents to join the CSF in which their parents
`are participating. While the examples described herein may be described with reference to a
`
`Fortinet Ex. 2016, Page 11 of 87
`
`

`

`single CSF within a private network, it is contemplated that network security devices may be
`
`divided into multiple CSFs and may participate in a single CSF or multiple CSFs.
`
`[00041] (cid:9)
`
`Tunnel based communication module 204 establishes tunnels between NSD 200
`
`and its parent, if any, and each of its children, if any. Tunnel based communication module
`
`204 also enables communication of periodic keep-alive messages and on-demand query
`
`messages among parent nodes and their respective child nodes. As noted above, the tunnels
`
`may be established by a backend daemon (now shown) running on NSD 200 and NSD 200
`
`may issue queries or commands to downlevel daemons via a forward daemon (not shown)
`
`running on NSD 200.
`
`[00042] (cid:9)
`
`In an aspect, CSF construction module 202 can be configured to dynamically
`
`construct a CSF based on hierarchical interconnections among multiple network security
`
`devices deployed within a protected network. In another aspect, the CSF can be constructed
`
`by determining relative positions of each network security device within the CSF based on at
`
`least one identifier, such as an IP address, a type of NSD, the serial number of the NSD, a
`
`manufacturing year/date/time of the NSD, functionality of the NSD,
`
`location/position/configuration of the NSD in the network, importance of the NSD in the
`
`network, among other like parameters. Each network security device, except root node
`
`network security device and leaf-node network security devices, can be configured to have an
`
`single parent node and one or more child nodes, and each NSD of the CSF can be constrained
`
`to allow queries to be issued only in the downstream direction.
`
`[00043] (cid:9)
`
`In an exemplary implementation, the at least one identifier that is associated
`
`with each NSD can be the IP address, type of NSD, hierarchy of NSD with respect to each
`
`other or with respect to OSI model, configuration/serial number/location of the NSD, among
`
`any other identifier attribute of the NSD.
`
`[00044] (cid:9)
`
`In an aspect, tunnel based communication module 204 can be configured to
`
`establish, by a backend daemon running on NSD 200, a tunnel between a directly connected
`
`upstream network security device (not shown), if any, and each directly connected
`
`downstream NSD (not shown), if any.
`
`[00045] (cid:9)
`
`Communication module 204 can further be configured to enable communication
`
`of periodic keep-alive messages and on-demand query messages among the upstream
`
`network security device and the one or more downstream network security devices of the
`
`particular node. In an exemplary implementation, each network security device participating
`
`in the CSF can be configured to be aware of only those of the network security devices that
`
`- 12 -
`
`Fortinet Ex. 2016, Page 12 of 87
`
`

`

`are directly connected to it. By limiting the awareness of the NSD devices in the CSF, better
`efficiency in term of network routing, security, and management can be achieved.
`[00046] (cid:9)
`
`In another aspect, the proposed system can configure each NSD node in such a
`way that one or more downstream network security devices of a particular NSD of the NST
`cannot query the particular NSD (which is the upstream network security device for the
`downstream NSDs). The system can therefore configure each NSD so as to restrict an
`upstream NSD from being queried by a NSD that is lower in the CSF hierarchy.
`
`[00047] (cid:9)
`In an exemplary implementation, the root node NSD can be aware of complete
`topology of the NST by means of one or more local daemons configured withing each NSD.
`The root node NSD does not have any upstream NSD attached therewith, and similarly, leaf
`node NSDs do not have any downstream NSDs attached thereto. The root node NSD can act
`as master NSD, and can perform various network management and resource optimization
`functions in the network or in the CSF.
`
`[00048] (cid:9)
`FIG. 3 illustrates an exemplary flow of query handling by an NSD of a CSF in
`accordance with an embodiment of the present invention. According to one embodiment,
`each NSD implements two separate daemons — one, the forward daemon, which, among other
`things, issues queries to downstream NSDs and receives and routes responses to queries
`received from downstream NSDs, and another, the backend daemon, which, among other
`things, receives and processes queries from upstream NSDs (via a RESTful API, for
`example). In an exemplary implementation, each NSD can be configured to handle query and
`response packets based on the content of the respective packet and the specified query or
`return path. In an exemplary implementation, the response packet can include the destination
`address (which is the same as the source address of query packet), a return path including
`addresses of intermediate node(s)/hop(s)/NSD(s) through which it needs to be routed, along
`with the response data. In an exemplary implementation, return path and the query path can
`be same or different. In an exemplary implementation