A method for topology discovery

Abstract

Embodiments of the present disclosure relate to authentication links in micro-branch deployments. Systems and methods for authentication links and firewall optimization in micro-branch deployments are provided, the micro-branch deployments comprising multiple chained access points (APs) and gateway APs. The topology of the micro-branch deployment can be determined by enhanced hierarchical beacons. Based on the determined topology, an authentication chain is developed, through which client devices associated with APs in multiple chained APs can be authenticated and granted access to the APs. When authenticating a client device, firewall optimization is performed to implement access control rules only at the AP to which the client device is associated.

Description

Background Art

[0001] A software-defined wide area network (SDWAN) is a network topology that uses the principles of software-defined networking (SDN) to interconnect sites of a wide area network (WAN), such as separating the control plane of service management from the data forwarding plane. SDWAN supports infrastructure consolidation through network function virtualization (NFV). NFV reduces the management overhead and hardware costs of adding network functions to a WAN by virtualizing network functions using virtual machines on more common and cheaper "commodity" hardware. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] According to one or more various embodiments, the present disclosure is described in detail with reference to the following drawings. These drawings are provided for illustration purposes only and merely depict typical or example embodiments.

[0003] Figure 1 An example network including a micro-branch deployment is illustrated to which embodiments of the techniques disclosed herein may be applied.

[0004] Figure 2 An example of daisy-chaining of access points in a micro-branch deployment is illustrated.

[0005] Figure 3 An example of micro-branch deployment topology discovery according to one embodiment is illustrated compared to conventional topology discovery.

[0006] Figure 4 An example of automatic authentication proxy chaining according to one embodiment is illustrated compared to conventional authentication.

[0007] Figure 5 An example of firewall optimization according to one embodiment is illustrated.

[0008] FIG. 6A to FIG. 6B is a block diagram of an example computing component or device for micro-branch topology discovery according to one embodiment.

[0009] Figure 6C is a block diagram of an example computing component or device for firewall optimization according to one embodiment.

[0010] Figure 7 are example computing components that may be used to implement various features of the embodiments described in this disclosure.

[0011] The drawings are not exhaustive and do not limit the disclosure to the precise forms disclosed. DETAILED DESCRIPTION

[0012] Various embodiments relate to systems and methods for authentication chaining in micro-branch deployments, which can solve the problem of multiple firewalls in daisy-chained network topologies, such as where APs can be daisy-chained / connected in series. First, an instant access point (IAP) (e.g., controllerless AP) hierarchical beacon mechanism can be enhanced to discover the branch parent-child network topology tree of the micro-branch deployment. Second, information about the topology can be used to build an authentication proxy chain. When a client device is connected to the micro-branch deployment network, the authentication proxy chain from the leaf AP to the gateway AP (GAP) can be automatically triggered. Third, and as a result of this proxy chaining process, each AP in the micro-branch deployment can correctly supply client device ingress and firewall policies while avoiding duplicate authentication transactions and optimizing overall business flow processing time.

[0013] It should be noted that the terms "optimize," "optimal," and the like as used herein can be used to mean making or achieving a performance as efficiently or perfectly as possible. However, as one of ordinary skill in the art reading this document will recognize, perfection is not always achievable. Therefore, these terms can also encompass making or achieving a performance as well or efficiently as possible under given circumstances, or making or achieving a performance that is better than that achievable using other settings or parameters.

[0014] Software Defined Wide Area Network (SDWAN) allows network administrators to connect branch locations to core sites through a wide area network (WAN). The use of software defined networking (SDN) decouples network service decisions from various devices within the network, such as routers, switches, bridges, and other common network devices. This decoupling essentially turns each networking device into a simple packet forwarding device. SDWAN sets up potential service paths through each network device based on client policies (such as QoS requirements, bandwidth, etc.) to connect branch locations within the SDWAN to core sites or data centers, which are provided to each network device through a control channel. Instead of deciding how to route traffic when data is received, network devices only execute the routes identified by the SDWAN administrator.

[0015] As alluded to above, the use of SDWAN supports the virtualization of network services across the WAN. Network Function Virtualization (NFV) reduces the management overhead and hardware cost of adding network functions to the WAN by virtualizing network functions using virtual machines on more common and cheaper "commodity" hardware, rather than proprietary, dedicated hardware (traditionally required). For example, functions such as routing, load balancing, and firewalls can be operated as virtual machines (VMs) hosted at a data center and / or in the cloud. However, NFV focuses on virtualized functions and does not care about how data packets are routed to the virtual machines running network functions. SDWAN combined with NFV provides a more fully realized virtual network, where SDWAN provides routing policies for business flows from branch locations to core sites or data centers hosting NFV virtual machines. Branch users are able to leverage these resources through SDWAN, thereby reducing reliance on expensive proprietary hardware and reducing the amount of computing hardware required at branch sites of the WAN.

[0016] SDWAN can be implemented by creating a virtual overlay that is transport-independent and abstracts the underlying private or public network connections. These network connections may include Multi-Protocol Label Switching (MPLS), Internet broadband, fiber, wireless, or Long Term Evolution (LTE), to name a few. In some examples, virtual private network (VPN) tunnels are created between WAN sites to allow private, secure interconnection across potentially vulnerable and insecure public links (e.g., Internet links). Clients can maintain existing WAN links and use these tunnels to implement an overlay SDWAN to optimize bandwidth by directing WAN traffic to or from other WAN sites using identified routes that include these tunnels. Therefore, SDWAN can be used to centralize network control across the entire WAN. Remote users, such as branch users, are able to run applications within the network using resources hosted in data centers and / or clouds.

[0017] As a practical example, traditional branch deployments support client connectivity requirements across different geographic locations for various types of business operations. Sites located in remote geographic locations act as branch offices, while the headquarters or head office acts as a data center, which hosts network resources to store, manage, and distribute data. The head office also hosts a centralized virtual private network (VPN) management system to aggregate traffic from remote branch sites. SDWAN helps connect multiple LANs to a central enterprise network or a distant data center.

[0018] For micro-branch deployments, no dedicated gateway device is required. Instead, a single gateway AP (GAP) can be used as a gateway to the WAN. Additional APs can be added "below" the GAP to expand the wireless coverage in a micro-branch deployment. AP can refer to a network device that allows wireless compatible devices such as client devices, stations (STAs), etc. to connect to a wired network. Therefore, the AP essentially acts as an extension mechanism from an existing wired network to a community of wireless client devices. It should be understood that a gateway typically refers to an AP with Network Address Translation (NAT) routing and Dynamic Host Control Protocol (DHCP) server capabilities.

[0019] In a micro-branch deployment, the GAP "owns" a public IP address, provides gateway / gateway-like functionality (e.g., DHCP, NAT, routing, etc. capabilities), and may also host a VPN client to provide secure connectivity to a remote (e.g., head office) data center or (multiple) other cloud services based on the needs of the micro-branch. The configuration between the GAP of a micro-branch deployment and any additional APs is typically different because of their respective roles in the micro-branch deployment.

[0020] Before describing embodiments of the disclosed systems and methods in detail, it is useful to describe an example micro-branch deployment network with which the disclosed systems and methods may be implemented in various applications. Figure 1 An example of a network 100 including a micro-branch deployment is illustrated. In this example, the network 100 may include a data center 102 to which a single-AP micro-branch deployment 120 and a multi-AP micro-branch deployment 130 are operatively connected. Moreover, part of the network 100 is a provisioning system, such as a cloud-based zero-touch provisioning system / service 114. As mentioned above, an SDWAN such as WAN 112 allows various elements / entities of the network 100 to be interconnected. It should be noted that the embodiments described herein may refer to the use of an SDWAN, or may describe features / functionality in the context of an SDWAN. However, embodiments of the present disclosure are not limited to SDWANs, but are contemplated for use in / in the context of traditional WANs.

[0021] As implied above, the data center 102 can represent an enterprise head office. The data center 102 can include a controller or core switch 104 to which a DHCP server 106 and a policy management platform 108 are operatively connected. It should be understood that the functionality of the element 104 may be different depending on how the connection between the data center 102 and the remote branches (micro branches 120, 130 in this example) is achieved. Some virtual LANs may be layer 3 routed, in which case the VPN concentrator can send the business flow to a core switch, such as a core switch 104 that can be a high-speed core switch. The core switch 104 can then route the packets of the flow to the necessary subsequent hops. Alternatively, in the context of a layer 2 connected virtual LAN, the VPN concentrator can simply route the GRE packets (described below) to the controller, in which case the controller will be the element 104 that also acts as a controller.

[0022] As will be appreciated by those skilled in the art, DHCP server 106 can refer to a network element that dynamically assigns IP addresses and other network parameters to each device on the network. Policy management platform 108 can be implemented to securely / correctly connect devices such as client devices to the network. For example, policy management platform 108 can provide a new device onboarding process, grant different levels of access to the network, maintain network security, etc.

[0023] like Figure 1 As further illustrated, the data center 102 is connected to the micro-branch 120 via an overlay tunnel 116A. As mentioned above, VPN tunnels can be established between sites, in this case the data center 102 and the micro-branch 120, to create an SDWAN overlay network. Specifically, the overlay tunnel 116A can connect the AP 122 of the micro-branch 120 to the front-end gateway 110, which can act as a VPN concentrator and overlay terminator (using, for example, the Generic Routing Encapsulation (GRE) tunneling protocol) to terminate the VPN tunnel, in this instance, the overlay tunnel 116A, thereby providing routing from the micro-branch 120 to the data center 102. Similarly, the micro-branch 130 (which is a multi-AP micro-branch compared to the micro-branch 120, including the root AP 132 and the leaf APs 134A to 134C) can be operatively connected to the data center 102 via the overlay tunnel 116B.

[0024] The micro-branch 120 is a single-AP micro-branch in which one or more client devices (such as client devices 124A to 124E) can associate to an AP, such as AP 122 (wirelessly or via a wired connection) to allow connectivity with the data center 102. The micro-branch 130 is a multi-AP micro-branch in which, in this example, multiple APs 134A to 134C are operatively connected to a root AP 132 through which connectivity with the data center 102 can be achieved. The micro-branch 130 can include one or more client devices, such as client devices 138A to 138C, each of which can be directly associated to the root AP 132 or one of the APs 134A to 134C. In this example, the micro-branch 130 can also include an unmanaged switch 136 to which additional client devices (such as client devices 138D to 138E) are connected.

[0025] Now refer to Figure 2 , another micro-branch deployment 200 is illustrated, where the micro-branch deployment 200 has a daisy-chain topology / hierarchy with respect to its APs. As mentioned above, in a micro-branch deployment (such as micro-branch deployment 200), no dedicated gateway is required. Instead, a GAP (e.g., GAP 202) acts as a gateway to the WAN, and in this example, can be connected via an Ethernet connection (Eth-0) via the WAN port 203 of GAP 202. A first AP (AP 210) can be operatively connected to GAP 202, and in turn, a second AP (AP 220) can be operatively connected to AP 210, i.e., APs 210 and 220 are daisy-chained to GAP 202.

[0026] like Figure 2 As illustrated, two client devices 204 and 206 (e.g., laptops, phones, printers, or other computing devices) can be wirelessly associated to GAP 202. In this example, GAP 202 can be configured to operate as multiple virtual APs (VAPs). Those skilled in the art will appreciate that VAPs emulate multiple APs on a single physical AP. Each VAP may have its own unique service set ID (SSID), thereby segmenting the WLAN into multiple broadcast domains. Security can be customized / configured to control wireless client device access. In this example, when client device 204 is connected to GAP 202, it can be assigned a specific user role. It should be understood that each client device in the network (e.g., micro-branch deployment 200) can be operatively connected to the network 100 ( Figure 1)) are associated with a user role. The user role determines the network permissions of the client device, the frequency of re-authentication, applicable bandwidth contracts, etc. In this example, client device 204 (from the perspective of GAP 202) is associated with a user role (Role A). From the perspective of GAP 202 (Role B), a second client device (i.e., client device 206) associated to GAP 202 may have its own associated user role.

[0027] With respect to the AP 210 of the micro-branch deployment 200, a client device 212 (which can also be a laptop, a phone, other user / client device, etc.) can be associated with a VAP (VAP-X) configured on the AP 210. From the perspective of the AP 210, the client device 212 can be associated with a user role (Role A). However, assuming that the AP 210 is connected to / "under" the GAP 202, from the perspective of the GAP 202, the client device 212 can be associated with a user role (Role D). It should be understood that user roles can be assigned in a variety of ways based on the network configuration. In some embodiments, the assigned user role can refer to a static role (combined with a port) so that all client devices connected to the same port / VAP can be assigned the same user role. Alternatively, user role derivation can be used, which can be based on client device attributes such as MAC address, connection port, etc. Moreover, it should be understood that a user role can refer to a policy container, where typically different policies can be configured for different roles, although the same policy can be configured for different user roles. Typically, different user roles can be assigned to APs, wired client devices, and wireless client devices. This time, another client device 216 can be associated to AP 210 via an Ethernet connection and can be assigned a user role (role D). Yet another client device 222 can be associated to a VAP (VAP-X) of AP 220 and can be assigned its own user role (role A).

[0028] Assuming that AP 220 is daisy-chained to GAP 202 via AP 210, AP 210 may also assign a user role to client device 222, in this example, role D (e.g., client device 216). Moving up the chain to GAP 202, GAP 202 "sees" each of the client devices associated to APs 210 and 220, and may therefore assign a specific user role to each of these client devices, in this case, client device 216 (associated to AP 210), role D. GAP 202 may also assign a user role to client device 222 (associated to AP 220), namely, role D. It can be appreciated that permissions (e.g., firewall policies) may not necessarily be consistent across all APs (GAP 202, AP 210, AP 220). It should also be appreciated that AP 220, AP 210, and GAP 220 are connected via wired connections (e.g., Ethernet), and that the respective user roles assigned to those client devices associated with the daisy-chained APs are served by the Eth-X server (capable of serving its own connected wired client devices as well as any other wired / wireless clients served by the downstream APs. The VAP-X server typically only serves wireless client devices connected to the VAP ports.

[0029] Conventionally, to resolve this firewall inconsistency, the network administrator can remove the port access control list (ACL) policy for the wired (Eth-X) ports. For example, the network administrator can configure all wired ports to operate in trusted mode, or configure a "permit-all" port ACL to allow firewall processes for these wired ports. However, although the firewall inconsistency is resolved, configuring the wired ports in this manner may introduce potential security risks to the network. For example, an attacker may connect a client device (such as a laptop computer) to one of the wired ports of the daisy-chained APs. Because the wired port operates in trusted mode, or allows the firewall process to be bypassed without performing authentication on the client device, the attacker will be able to access the micro-branch deployment network 200. This in turn allows the attacker to have full network access to the main corporate network (e.g. Figure 1 data center 110 and other branch networks (such as micro-branch networks 120, 130 ( Figure 1 )).

[0030] Another conventional mechanism for avoiding firewall inconsistencies is to link authentication and use role derivation, such as using Radius authentication. For example, when client device 222 connects to an AP (e.g., AP 220), Radius authentication can be immediately triggered on the connected wireless SSID (VAP-X), and the user role (e.g., role A) can be derived. When the (multiple) packets of client device 222 arrive at the "upper" AP (here, AP 210), Radius authentication can be triggered again for the same client device (client device 222) on the wired port (Eth-X) of AP 210. Therefore, the same user role can be derived and applied to the wired port of AP 210. When the packets of client device 222 arrive at GAP 202, the same authentication and user role derivation may occur. Although the firewall processing remains consistent between APs (and GAPs), redundant authentication transactions are introduced and additional flow processing time is generated.

[0031] In a typical SDWAN / WAN branch deployment, a dedicated gateway device represents the gateway to the WAN. As part of the user configuration, enabling an authentication proxy (such as a Radius proxy on such a gateway device) can involve each SSID / port being mapped to a gateway device. Therefore, the AP knows that the gateway is an authentication proxy device. When a client device connects to an AP, the AP sends an authentication request to the gateway device, which in turn authenticates the backend authentication server via the authentication proxy. When the authentication response is returned from the authentication server, both the gateway device and the AP can determine the user role assigned from the authentication proxy.

[0032] However, even in this scenario, problems may arise. For the coverage case, these client devices will fall into the coverage vlan list, the gateway device will set the data path user entry, and apply the derived user role to the gateway data path. It should be understood that coverage in this context can refer to the use of a tunnel (such as a GRE tunnel) to send client device traffic between the AP and the gateway device. However, the same user role is not used by the AP (again resulting in firewall inconsistencies). Therefore, the administrator needs to configure separate user roles for the AP's SSID / wired port profiles, which is different from the authentication and user role derivation process. While this approach solves the problem of redundant / duplicate authentication transactions, it still introduces additional management work, not to mention that the administrator must be very clear about those policies that need to be configured and enforced by the gateway device and the AP.

[0033] For the bottom layer case, those clients will not fall into the overlay vlan list, the gateway does not set the data path user entry, and no user role will be applied to the gateway data path. The bottom layer in this context can refer to the directly bridged services in the micro-branch deployment (no GRE tunnel), so all APs in the micro-branch deployment will see the same client devices in the micro-branch deployment, that is, there is no overlay within the micro-branch. Instead, the user entry will be in the AP data path and the derived user role will be applied by the AP. While this is sufficient when the AP is only one hop away from the gateway, in the case where the APs are linked through their wired ports, failure to apply ACL policies on these wired ports will again lead to security risks. If the authentication and user role derivation is configured for each wired port, repeated authentication transactions and additional flow processing time will again become a problem in daisy-chained APs. As discussed previously, unlike typical branch deployments, in micro-branch deployments, there are no dedicated gateways, only GAPs.

[0034] As mentioned above, the various embodiments ultimately involve applying ACL rules only to the AP to which the client device is directly connected / associated. Other APs in the link path to the GAP of the micro-branch deployment do not need to have any rules applied to avoid redundant authentication and user rule derivation processes. These other APs only need to know that a particular client device is associated / connected to a leaf AP so that when receiving traffic / packets from the client device, the normal processing / operations regarding authentication / user rule derivation can be ignored or otherwise bypassed. It should be noted that the various embodiments do not rely on cloud services / cloud-based functionality. The first step to achieve this independence involves discovering the branch parent-child topology of the micro-branch deployment.

[0035] When an AP is configured according to the "AP Configuration Service" operation, a unique "branch key" will also be pushed from the cloud to all APs within the branch. In the case of a micro-branch, the "micro-branch gateway AP" flag will be pushed from the cloud AP configuration service to the GAP deployed in the micro-branch, such as GAP 202 ( Figure 2 ). The micro-branch gateway AP flag will be saved in a memory unit, such as the flash memory of the GAP. According to one embodiment, the micro-branch gateway AP (or simply GAP) flag can be used to indicate that the specific GAP is the "IAP host" of the micro-branch. After the GAP is set as the "IAP host", the regular IAP hierarchical discovery process can be started.

[0036] That is, a GAP may periodically announce its presence via a hierarchical beacon that is periodically broadcast (e.g., every second) through all of its wired ports. The hierarchical beacon can be a layer 2 (L2) broadcast data packet similar to a bridge protocol data unit (BPDU), i.e., a message transmitted by bridges to each other to support determination of spanning tree topology. Within the message, a field called "root IP" includes the management IP address of the GAP.

[0037] Reference Figure 3 , and according to the conventional hierarchical beacon process 300 when the downstream AP (e.g., AP 210) receives the hierarchical beacon message from GAP 202 in operation 302, the AP (e.g., AP 210) becomes aware of the presence of a root AP with the IP address of the GAP in the network. In other words, AP 210 becomes aware of the presence of GAP 202. The downstream AP (AP 210 in this example) may then send a hierarchical acknowledgment (ACK) to the root AP (GAP 202 in this example) in operation 304, wherein the ACK contains a field called "AP_IP". That is, AP 210 sets the AP_IP address to its IP address. In this way, the root AP (i.e., GAP 202) will know the IP address of the downstream AP, i.e., the IP address of AP 210. If any downstream AP dies or restarts for some reason, such downstream AP will not be able to transmit the hierarchical ACK back to the GAP. Therefore, the GAP is able to remove the AP from its AP database, leaving only those downstream APs active within the micro-branch deployment.

[0038] Similarly, when a hierarchical beacon is received by AP 220 from the root AP (i.e., GAP 202) in operation 302, it may also respond to the hierarchical beacon by transmitting a hierarchical ACK back to GAP 202, which includes its IP address within the AP_IP field of the hierarchical ACK in operation 306. Therefore, the GAP of the micro-branch deployment is able to know all APs in the micro-branch deployment network. Similarly, the child APs in the micro-branch deployment are able to know their root AP / GAP. For example, in a branch image upgrade scenario, since the root AP knows the IP addresses of its downstream APs, the root AP is able to collect more information about the downstream APs, such as AP type information. The root AP can then choose to directly download all required AP images, or instruct some APs to download upgrade images from a remote image server.

[0039] While the above-described discovery mechanism allows a downstream AP to learn the root AP of a micro-branch deployment, the downstream AP does not necessarily know which upstream AP is its "exact" / direct parent AP. Therefore, various embodiments provide enhancements to conventional IAP hierarchical discovery processes or mechanisms. Specifically, and in addition to the "root IP" field already included in the hierarchical beacon, in addition to the "root IP" field already included as part of the hierarchical beacon, an "AP_IP" field is also added to the hierarchical beacon. The branch key AP received from the cloud can be used for pre-shared key (PSK) authentication and triple data encryption standard (3DES) encryption between APs, thereby providing higher security for the topology discovery process.

[0040] As a result of the addition of the "AP_IP" field to the hierarchical beacons broadcast by the GAP, the GAP may begin sending its periodic hierarchical beacons, setting the "root IP" and "AP_IP" fields to match its own management IP address. Figure 3 , an enhanced hierarchical discovery process 310 is illustrated. As an example, when AP 210 receives a hierarchical beacon from its upstream port in operation 312, AP 210 realizes that there is a parent AP in its micro-branch deployment network, and the parent AP is also the root AP of the micro-branch deployment network. AP 210 can then respond to the hierarchical beacon in operation 314 by transmitting a hierarchical ACK to GAP 202 through the same upstream port. In this way, GAP 202 learns that there is a branch AP, that is, downstream AP 210, in its micro-branch deployment network.

[0041] In operation 316, AP 210 will modify the original hierarchical beacon received from GAP 202 by changing the "AP_IP" field to reflect its own IP address (rather than the IP address of GAP 202), and can then send the (new) modified hierarchical beacon to all of its downstream wired ports. When AP 220 receives the modified hierarchical beacon from its upstream port, AP 220 learns that GAP 202 is the root AP of the micro-branch deployment network, and AP 210 is the parent AP of AP 220. In operation 318, AP 220 can then send its own hierarchical ACK to GAP 202 via the upstream port from which it received the modified hierarchical beacon from AP 210. Due to the daisy-chain topology, the hierarchical ACK transmitted by AP 220 reaches AP 210 on the way to GAP 202. At this point, AP 210 will learn that it has a child AP, i.e., AP 220. AP 210 may then relay the hierarchical ACK from AP 220 to GAP 202. At this point, GAP 202 will be aware of the presence of another branch AP (AP 220) connected to its downstream wired port.

[0042] It should be understood that the above process / method can be repeated depending on how many APs in the micro-branch deployment receive hierarchical beacons from the root AP / GAP, and how many APs respond with their corresponding hierarchical ACKs. Because hierarchical beacons are sent periodically, for example every second, the micro-branch topology can be continuously discovered / determined and updated. It should be noted that hierarchical beacons should only be considered if they are received from / via the upstream port of the AP. Therefore, any beacons received from / via the downstream port of the AP will be discarded / ignored. Similarly, hierarchical ACKs should only be considered if they are received from the downstream port of the AP, and any hierarchical ACK messages received from / via the upstream port of the AP will be discarded / ignored. If this scheme is not followed, the AP will not be able to distinguish between the upstream / parent AP or GAP and the downstream / child AP.

[0043] As also mentioned above, the second step to achieve the goal of applying ACL rules only to the AP to which the client device is directly connected / associated without redundant authentication / user rule derivation involves building an authentication proxy chain using the micro-branch deployment topology. In this way, when a client device is connected to the micro-branch deployment network, this authentication proxy chain from the leaf AP to the gateway AP (GAP) can be automatically triggered.

[0044] As implied above, and as Figure 4 As illustrated, a conventional authentication method 400 for a client device in a micro-branch deployment where APs are daisy-chained involves an authentication request from each AP traversed by a client device group / traffic to the same authentication server. Figure 4 200). When a packet is received by AP 210 (shown in FIG. 201 ), authentication is triggered by requesting authentication from a remote authentication server (e.g., Radius authentication from a remote Radius server). When the packet traverses AP 210, authentication is again triggered using a remote Radius server, and so on, until passing through GAP 202. However, this results in redundant authentication operations being triggered.

[0045] Instead, and in accordance with one embodiment, conventional authentication can be replaced with an automatic authentication proxy link as reflected by method 410. Figure 4As shown, the authentication client (e.g., Radius client) in the AP is configured or set to initiate access request messages, such as Radius access requests, to any client device associated with the AP, and exchange authentication messages / packets with the corresponding authentication server (e.g., Radius server). Deviating from conventional authentication, the authentication server to which the Radius access request is directed is directed to the parent AP of the AP. For example, AP 220 sets its authentication server to its parent AP (AP 220 discovers / learns through the micro-branch deployment topology discovery mechanism discussed above). In turn, AP 210 sets its authentication server to its parent AP, which is the root AP / GAP 202 in this example (again discovered through the above-mentioned topology discovery mechanism). At GAP 202, the authentication server is the actual Radius server to which the Radius access request is ultimately processed. It should be understood that at GAP 202, the network administrator will set the "real" authentication server because GAP 202 has no uplink / parent AP. In other words, the parent AP acts as a proxy authentication server (proxy chain) through which the authentication access request is relayed until the actual authentication server is reached.

[0046] For example, by means of the micro-branch topology discovery process, AP 220 may be determined to be a child AP (its parent AP) of AP 210. AP 210 may internally set or specify certain information, whereby AP 220 is added or entered into the authentication / Radius acceptance list, so that it can accept any authentication / Radius access request from AP 220. AP 210 may also set or specify that GAP 202 is an authentication / Radius server, so that when AP 210 receives an authentication / Radius access request from AP 220, the request may be proxied to GAP 202. In the opposite direction, when GAP 202 receives an authentication / Radius access response that refers to the same client device MAC address, GAP 202 knows that the authentication / Radius access response is related to the authentication / Radius client (AP 210 in this case). Therefore, GAP 202 may send / forward the authentication / Radius access response to AP 210. AP 210 does this in kind by sending / forwarding an authentication / Radius access response to its authentication / Radius client (AP 220).

[0047] As mentioned above, the third step in achieving firewall policy consistency involves firewall optimization, where only the AP to which the client device is directed to connect / associate enforces the privileges / rules corresponding to the user role assigned to the client device. Figure 5, client device 222 may attempt to connect to an AP, such as AP 220, from a WLAN SSID or a wired port. For example, consider that client device 222 attempts to connect to AP 220 via a WLAN SSID. AP 220, acting as an authentication client (e.g., a Radius client), constructs an access request message, such as a Radius access request, which AP 220 sends to its parent AP (in this case, AP 210). Again, discovering the micro-branch deployment tree topology causes each AP in the micro-branch deployment to learn / discover its parent / child AP (if any). The access request message (e.g., Radius access request) may include the following information: User-Name <=>user name; Calling-Station-Id <=>client device MAC address; Network-Profile <=>SSID profile name or wired port profile name; NAS-Port-Type <=>get wired / wireless type information. It should be understood that the network profile refers to a new vendor-specific attribute (VSA) that contains the SSID name or wired port profile name. This information helps the GAP (e.g., GAP 202) find the correct authentication server, e.g., Radius server, for the SSID to which the client device 222 is attempting to connect. When AP 210 (acting as a Radius proxy) receives this Radius access request, AP 210 sends the access request to GAP 202. The result is an authentication (e.g., Radius) request chain 504. GAP 202 decodes the Radius access request, learns the "SSID Profile Name" included in the request message, and then uses that name to determine the correct Radius server (configured by the network administrator) to which the access request message should be forwarded.

[0048] If an authentication server is configured, the GAP 202 will send an access request message to the authentication server. The GAP 202 will expect to receive an access accept or reject response, such as a Radius access accept or a Radius access reject response. After the GAP 202 receives the expected authentication response, the GAP 202 sends the authentication response to the AP 210. It should be noted that if the authentication server is temporarily unreachable or the GAP 202 cannot find the authentication server for this particular access request message, the GAP 202 will use a fallback mode by sending an authentication access accept response directly to the AP 210. The GAP 202 can also set a trusted user entry (with the MAC address of the client device 222) to the data path. This can ensure that other data packets from the client device 222 will not trigger the authentication process on the GAP 202. Moreover, the GAP 202 will not apply the derived user role to the data path of the GAP 202, so that those data packets from the client device 222 will not be unrestricted by the firewall of the GAP 202.

[0049] Otherwise, when the same response arrives at AP 210, AP 210 will follow suit. That is, AP 210 may send an authentication access-accept response to AP 220, and set up a trusted user entry for the data path to AP 210. This trusted user entry (with the MAC address of client device 222) again ensures that no further authentication is required for client device 222. Likewise, AP 210 will not apply the derived user role to its data path, so that client device 222 will not be restricted by the firewall of AP 210.

[0050] When AP 220 receives the authentication access response, AP 220 consumes the response message because it is the authentication client of client device 222. The result is an authentication response chain 506. AP 220 can thereby end the authentication chaining process and establish a normal / untrusted data path user portal, which can be applied with the derived user role based on the authentication (Radius) VSA in operation 508. In the case where the fallback mode is used, since GAP 202 will not send any VSA for role derivation, AP 220 can simply apply the default post-authentication user role for that SSID / wired port. It should be understood that in the authentication / Radius response, a field is used to indicate which user role the AP should apply to a particular client device / user. For example, a network administrator can use a string such as "guest" specified at the actual authentication server. Therefore, when AP 220 receives the authentication access response, it decodes the payload and knows the desire to apply the "guest" user role to a particular client device. AP 220 can search its local configuration to determine what is configured for the guest user role. In most instances, there will already be user roles in the configuration, but if user roles are not configured, a default user role can be used for the specific SSID / wired port.

[0051] It should be noted that if the SSID / wired port of the AP is configured as OPEN or PSK, MAC authentication can be automatically enabled for the SSID / wired port. This will trigger the same authentication and the same link process. However, since GAP 202 cannot find a valid authentication server based on the "network profile" information, it will use the above-mentioned fallback mode to send an authentication response to the downstream AP (e.g., AP 210 and 220). It should be noted that the embodiments described herein refer to Radius authentication. Radius authentication is just one possible authentication mechanism / system that can be used. Other embodiments consider using other authentication mechanisms besides Radius, such as LDAP, TACACS+, XTACACS, etc.

[0052] Fig. 6A 6 is a block diagram of an example computing component or device 600 for performing micro-branch topology discovery according to one embodiment. The computing component 600 may be, for example, a controller, a processor, or any other similar computing component capable of processing data and implementing the functionality of a GAP. Fig. 6A In the example implementation of , computing component 600 includes a hardware processor 602 and a machine-readable storage medium 604 .

[0053] Hardware processor 602 may be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions stored in machine-readable storage medium 404. Hardware processor 602 may retrieve, decode, and execute instructions, such as instructions 606 to 610, to control processes or operations for establishing connections, synchronizing, and publishing routes / status. As an alternative or in addition to retrieving and executing instructions, hardware processor 602 may include one or more electronic circuits including functional electronic components for executing one or more instructions, such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other electronic circuits.

[0054] A machine-readable storage medium, such as machine-readable storage medium 604, may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, machine-readable storage medium 604 may be, for example, a random access memory (RAM), a non-volatile RAM (NVRAM), an electrically erasable programmable read-only memory (EEPROM), a storage device, an optical disk, etc. In some embodiments, machine-readable storage medium 404 may be a non-transient storage medium, where the term "non-transient" does not encompass transient propagating signals. As described in detail below, machine-readable storage medium 604 may be encoded with executable instructions, such as instructions 606 to 608.

[0055] The hardware processor 602 may execute instructions 606 to broadcast a hierarchical beacon identifying the GAP as a root AP. It should be understood that the computing component 600 in some embodiments may be a GAP in a micro-branch deployment. As mentioned above, as a GAP in a micro-branch deployment, the hierarchical beacon process may be adapted by adding an AP_IP identifier / indicator to the hierarchical beacon in addition to the root_IP identifier / indicator. That is, the AP_IP and root_IP identifiers / indicators are set to reflect the management IP address of the GAP.

[0056] The downstream AP receiving the hierarchical beacon is aware of the presence of a parent AP, in this case a GAP, which is also the root AP of the micro-branch deployment. The downstream AP can respond to the hierarchical beacon with a hierarchical confirmation. In this way, the GAP learns the presence of a child AP or a downstream branch AP. The downstream branch AP can then modify the initially received hierarchical beacon by changing the AP_IP identifier / indicator to reflect the IP address of the downstream branch AP itself, and send the modified hierarchical beacon to its downstream wired port to broadcast to other downstream APs in the micro-branch deployment. That is, the hardware processor 602 can execute instructions 608 to receive a hierarchical confirmation indicating the presence of one or more downstream APs from one or more downstream APs, wherein the hierarchical confirmation responds to an iteratively modified version of the hierarchical beacon relayed by each downstream AP in the one or more downstream APs. Although some embodiments are described in the context of multiple downstream APs, the client device can be connected / associated to a single downstream AP and can be firewalled by the GAP (e.g., an Ethernet downstream port). Therefore, the embodiments described herein may also be applicable to topologies including a single downstream AP.

[0057] It should be understood that the GAP also broadcasts hierarchical beacons on its downstream wired ports, and any downstream branch AP receives the original or modified (multiple) hierarchical beacons on its corresponding upstream wired ports. This process can continue until the micro-branch topology is discovered from the perspective of the GAP and any AP in the micro-branch deployment.

[0058] Figure 6B 6 is a block diagram of an example computing component or device 610 for performing micro-branch AP topology discovery according to one embodiment. The computing component 610 can be, for example, a controller, a processor, or any other similar computing component capable of processing data and implementing the functionality of an AP. That is, Figure 6B This diagram illustrates micro-branch AP topology discovery from the perspective of a downstream AP. Figure 6B In the example implementation of , computing component 610 includes hardware processor 612 and machine-readable storage medium 614 , which may be, for example, other embodiments of hardware processor 602 and machine-readable storage medium 604 .

[0059] Hardware processor 612 may execute instructions 616 to receive a hierarchical beacon identifying the GAP as a root AP of the APs. As described above, the hierarchical beacon includes not only a root_IP identifier, but also an AP-IP identifier, where the GAP is reflected in the root_IP and AP_IP identifiers.

[0060] The hardware processor 612 may execute instructions 618 to transmit a hierarchical confirmation, for example, back to the GAP or its immediate parent AP in response to the hierarchical beacon. The hardware processor 612 may execute instructions 620 to modify the hierarchical beacon to reflect the AP's own IP address and broadcast the modified hierarchical beacon to one or more downstream APs. The hardware processor 612 may execute instructions 622 to relay the hierarchical confirmation received from one or more downstream APs to the GAP. In this way, the hierarchical beacon is iteratively modified as it passes through each downstream AP, and each downstream AP is aware of the GAP (identified via the root_IP identifier) ​​and its corresponding parent AP (identified via the iteratively modified hierarchical beacon), the modifications being generated for the changing AP_IP identifier during the process of passing through each of the APs in the micro-branch deployment. Each hierarchical confirmation received at the GAP also informs the GAP of each of its downstream branch APs.

[0061] Figure 6C 6 is a block diagram of an example computing component or device 630 for performing firewall optimization according to one embodiment. The computing component 630 may be, for example, a controller, a processor, or any other similar computing component capable of processing data and implementing the functionality of an AP. Figure 6C In an example implementation of , computing component 630 includes a hardware processor 632 and a machine-readable storage medium 634 , which may be, for example, other embodiments of hardware processor 602 and machine-readable storage medium 604 .

[0062] The hardware processor 632 can execute instruction 636 to initiate an authentication access request to the client device. It should be understood that the computing component can be a downlink AP of a micro-branch deployment to which the client device is associated. As mentioned above, an authentication proxy chain can be established, wherein each downlink AP in the micro-branch deployment points to an authentication server (for receiving authentication access requests), which is defined as the parent AP of the AP that generates / transmits the authentication access request. In other words, each AP that is a parent of a child AP acts as an authentication proxy until the parent in the authentication proxy chain is a GAP. The GAP can then point to the actual authentication server to perform client device authentication. Therefore, the hardware processor 632 can execute instruction 638 to transmit the authentication access request to the parent AP, and the authentication access request is pointed to the authentication server proxy defined as the parent AP.

[0063] The hardware processor 632 can execute instructions 640 to receive an authentication access response generated by an actual authentication server that is relayed by a parent AP defined as an authentication server proxy. That is, when the actual authentication server (for AP proxy in a micro-branch deployment) processes the authentication access request, the authentication access response can be similarly relayed downward through the AP until it reaches the AP that transmitted the authentication access request. As described above with respect to Figure 5 As described, a GAP deployed in a micro-branch may set a trusted user portal to prohibit firewall restrictions on data packets received from a client device at any AP other than the AP to which the client device is associated, thereby avoiding redundant application of firewall policies.

[0064] As mentioned above, various embodiments utilize the existing IAP hierarchical beacon mechanism in an enhanced manner (i.e., by including the AP_IP identifier in the hierarchical beacon broadcast by the GAP) so that the GAP / AP topology of the micro-branch deployment can be determined. The determined topology allows the automatic construction of an authentication proxy chain across the micro-branch deployment. When client devices connect to any AP in the micro-branch deployment, these client devices will be authenticated according to the authentication proxy chain. In this way, authentication is only triggered on the AP to which the client is connected, thereby avoiding redundant authentication transactions. The firewall is only executed on the AP to which the client is connected, avoiding the above-mentioned multiple firewall problems and improving flow processing time. Additionally, using, for example, Radius authentication, a single user role can be derived and applied to the connected AP, thereby negating the need for network administrators to coordinate their firewall policies across multiple devices, thereby simplifying management work. Therefore, the hardware processor can execute instructions 642 to apply user roles to client devices based on the authentication access response.

[0065] Figure 7 A block diagram of an example computer system 700 is depicted in which various embodiments described herein may be implemented. The computer system 700 includes a bus 702 or other communication mechanism for communicating information, one or more hardware processors 704 coupled to the bus 702 for processing information. The hardware processor(s) 704 may be, for example, one or more general purpose microprocessors.

[0066] The computer system 700 also includes a memory unit coupled to the bus 702, such as a main memory 706, such as a random access memory (RAM), cache, and / or other dynamic storage device, for storing information and instructions to be executed by the processor 704. The main memory 706 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 704. When stored in a storage medium accessible to the processor 704, such instructions cause the computer system 700 to become a special-purpose machine customized to perform the operations specified in the instructions.

[0067] The computer system 700 also includes a read only memory (ROM) 708 or other static storage device coupled to the bus 702 for storing static information and instructions for the processor 704. A storage device 710, such as a magnetic disk, optical disk, or USB thumb drive (flash drive), is provided and coupled to the bus 702 for storing information and instructions.

[0068] In general, as used herein, the words "engine", "component", "system", "database", etc. can refer to logic implemented in hardware or firmware, or to a collection of software instructions, possibly with entry and exit points, written in programming languages ​​such as, for example, Java, C or C++. Software modules can be compiled and linked into executable programs, installed in dynamic link libraries, or written in interpreted programming languages ​​such as, for example, BASIC, Perl or Python. It is to be understood that software components can be called from other components or from themselves, and / or can be called in response to detected events or interrupts. Software components configured for execution on a computing device can be provided on a computer-readable medium, such as a compressed disk, a digital video disk, a flash drive, a disk, or any other tangible medium, or provided as a digital download (and can be initially stored in a compressed or installable format that requires installation, decompression or decryption before execution). Such software code can be stored partially or completely on a memory device of an executing computing device to be executed by the computing device. Software instructions can be embedded in firmware, such as an EPROM. It is further appreciated that hardware components may include connected logic units, such as gates and flip-flops, and / or may include programmable units, such as programmable gate arrays or processors.

[0069] The computer system 700 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, makes the computer system 700 a special purpose machine, or is programmed to be a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 700 in response to the processor(s) 704 executing one or more sequences of one or more instructions contained in the main memory 706. Such instructions may be read into the main memory 706 from another storage medium such as the storage device 710. Execution of the sequences of instructions contained in the main memory 706 causes the processor(s) 704 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0070] As used herein, the term "non-transient medium" and similar terms refer to any medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such non-transient media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 710. Volatile media include dynamic memory, such as main memory 706. Common forms of non-transient media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a pattern of holes, RAM, PROMs and EPROMs, Flash EPROMs, NVRAMs, any other memory chips or cassettes and networked versions thereof.

[0071] Non-transient media are distinct from transmission media, but can be used in conjunction with transmission media. Transmission media participate in the transfer of information between non-transient media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that make up bus 702. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communications.

[0072] Computer system 700 also includes a communication interface 718 coupled to bus 702. Network interface 718 provides bidirectional data communication coupling with one or more network links connected to one or more local networks. For example, communication interface 718 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem for providing a data communication connection with a telephone line of a corresponding type. As another example, network interface 718 can be a local area network (LAN) card to provide a data communication connection with a compatible LAN (or a WAN component communicating with a WAN). A wireless link can also be implemented. In any such implementation, communication interface 718 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0073] A network link typically provides data communications to other data devices through one or more networks. For example, a network link may provide a connection to a host or data device operated by an Internet Service Provider (ISP) through a local network. The ISP, in turn, provides data communications services through a global packet data communications network now commonly referred to as the "Internet." Both local networks and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks and signals on the network link and through the communication interface 718 (carrying digital data to and from the computer system 700) are example forms of transmission media.

[0074] Computer system 700 can send messages and receive data, including program code, through the network(s), network links and communication interface 718. In the Internet example, a server can transmit the code for the requested application program through the Internet, an ISP, a local network and communication interface 718.

[0075] As used herein, the term "or" can be interpreted in an inclusive or exclusive sense. Moreover, the description of resources, operations or structures in the singular form should not be read as excluding plural forms. Unless otherwise specifically specified or otherwise understood as used in the context, conditional language (such as "can", "can", "may" or "can", etc.) is generally intended to convey that certain embodiments include and other embodiments do not include certain features, elements and / or steps. Unless otherwise clearly specified, the terms and phrases used in this document and their variations should be interpreted as open and non-restrictive. As an example of the foregoing, the term "including" should be read as meaning "including but not limited to", etc. The term "example" is used to provide an exemplary example of the item under discussion, rather than its exhaustive or restrictive list. The term "one" or "an" should be read as meaning "at least one", "one or more", etc. There are extended words and phrases (such as "one or more", "at least", "but not limited to" or other similar phrases in some examples) should not be read as meaning that in the instance where there may not be such an extended phrase, a narrower situation is intended or required.

Claims

1. A method for topology discovery, comprising: Broadcasting a hierarchical beacon from a gateway access point GAP, wherein the hierarchical beacon identifies the GAP as a root access point AP of a micro-branch deployment network; receiving, at the GAP, a hierarchical confirmation from one or more downstream APs, the hierarchical confirmation indicating the presence of the one or more downstream APs in the micro-branch deployment network, wherein the hierarchical confirmation is responsive to an iteratively modified version of the hierarchical beacon relayed by each of the one or more downstream APs, the iteratively modified version of the hierarchical beacon being generated by modifying a field of an IP address of a downstream AP; as well as Based on the received hierarchical confirmation, a topology of the micro-branch deployment network is discovered. 2 . The method of claim 1 , wherein the one or more downstream APs are implemented as chain APs that are operatively connected in series via respective wired ports of the one or more downstream APs.

3. The method of claim 2, wherein the broadcasting of the hierarchical beacon and the relaying of the iteratively modified version of the hierarchical beacon occur on a wired downstream port of the GAP and corresponding downstream ports of the one or more downstream APs, and wherein the reception of the hierarchical beacon and the iteratively modified version of the hierarchical beacon occurs on corresponding upstream ports of the one or more downstream APs.

4. The method according to claim 1, wherein the layered beacon includes a layer 2 broadcast data packet, the layer 2 broadcast data packet includes a root Internet Protocol ROOT_IP field and an AP_IP field, each of the root Internet Protocol ROOT_IP field and the AP_IP field reflecting the management IP address of the GAP before its iterative modification.

5. The method of claim 4, wherein the iteratively modified version of the hierarchical beacon includes a modified AP_IP field, the modified AP_IP field reflecting an IP address of a receiving downlink AP of the plurality of downlink APs.

6. A method for topology discovery, comprising: Receiving a hierarchical beacon at a downlink access point AP of a micro-branch deployment network, wherein the hierarchical beacon identifies a gateway access point GAP as a root AP of the micro-branch deployment network; transmitting, from the downlink AP, a hierarchical acknowledgment in response to the received hierarchical beacon; At the downlink AP, modifying the hierarchical beacon to reflect the IP address of the downlink AP itself, and broadcasting the modified hierarchical beacon to one or more additional downlink APs of the micro-branch deployment network; relaying a hierarchical acknowledgment received from the one or more additional downstream APs from the downstream AP to the GAP; as well as The downlink AP discovers the topology of the micro-branch deployment network based on the received hierarchical beacon and the received hierarchical confirmation.

7. The method of claim 6, wherein the downstream AP and the one or more additional downstream APs are implemented as chain APs operatively connected in series via their respective wired ports.

8. A method according to claim 7, wherein the broadcasting of the modified hierarchical beacon occurs on the wired downstream port of the downstream AP, the relaying of the received hierarchical confirmation occurs on the wired upstream port of the downstream AP, and wherein the reception of the hierarchical beacon from the GAP occurs on the wired upstream port of the downstream AP.

9. The method of claim 6, wherein the layered beacon comprises a layer 2 broadcast data packet, the layer 2 broadcast data packet comprising a root Internet Protocol ROOT_IP field and an AP_IP field, each of the root Internet Protocol ROOT_IP field and the AP_IP field reflecting the management IP address of the GAP.

10. The method of claim 9, wherein the modified hierarchical beacon includes a modified AP_IP field, the modified AP_IP field reflecting an IP address of the downstream AP.

Images