Patent Grant
11877334
The present disclosure relates to device address rotation on a wireless network.
In an effort to improve privacy of a mobile device user, many mobile operating system vendors are periodically changing (or “rotating”) a device address (e.g. a station address) used to identify a mobile device on a wireless network. By changing the device address, it can be more difficult for an eavesdropper to not only track a location of a mobile device user, but also, in some circumstances, monitor their online activities. While rotation of a wireless device's address can improve privacy, much of the legacy wireless network infrastructure was not designed to accommodate such address rotation, and in many cases, uses the device address as an identifier of the station for a variety of processing.
Overview
One aspect disclosed herein is a method performed by a wireless access point device, wireless network controller or other similar device to enabling rotation of a wireless client address. The method includes associating a wireless client device that is identified via a first device address; establishing, based on the associating, a first secure communication channel with the wireless client device; receiving, over the first secure communication channel, a first mapping of the first device address to a stable device address; performing first data communication with the wireless client device based on the first mapping; second associating the wireless client device, the wireless client device identified via a second device address; establishing a second secure communication channel with the wireless client device; receiving, over the second secure communication channel, a second mapping of the second device address to the stable device address; and performing second data communication with the wireless client device based on the second mapping.
Presented herein are embodiments generally direct to rotating a device address of a mobile wireless client device or wireless station (STA). As discussed above, while address rotation can improve the privacy of a mobile device user, legacy wireless network infrastructure was not necessarily designed to accommodate a mobile device address that changes over time. Thus, the disclosed embodiments provide for communicating a mapping of a station's OTA device address to a stable identifier, such as a stable device address (e.g. a stable Media Access Control (MAC) address. Thus, when a station rotates its OTA address from a first OTA device address to a second OTA device address, both device addresses map to a common stable identifier. This allows the wireless network infrastructure to identify that both OTA device addresses identify a common STA.
In some embodiments, after the mapping is communicated, the STA and access point (AP) or wireless local area network (LAN) controller (WLC) communicate by establishing a secure tunnel that identifies the STA via a device address that is subject to rotation. The secure tunnel encapsulates a set of second packets that identify the STA via a stable device address. The second packets, when received by the AP from the STA, and forwarded to other devices as appropriate, identify the STA via the stable device address. Similarly, when the AP sends data to the STA, a second packet identifying the STA via the stable device address is forwarded to the STA by encapsulating it in a frame that identifies the STA via its current OTA device address (that is subject to rotation).
In some embodiments, the mapping between the OTA device address and the stable device address is communicated to the AP via an action request frame. Some of the embodiments that utilize the secure tunnel discussed above, communicate a request to establish the tunnel via an action frame as well.
As the STA seeks to rotate its device address, the STA transmits an action request frame 212 to the AP 204. The action request frame 212 indicates a request to utilize tunneling for communication between the STA 202 and the AP 204. The action request frame 212 indicates a mapping between the first device address (e.g., “MAC1”) and a stable device address. In some embodiments, the stable device address is a device address assigned to the STA by its manufacturer. Upon receiving the action request frame 212, the AP records a mapping between the first device address and the stable device address indicated in the action request frame 212. The AP then transmits an action response frame 214, indicating the request for tunneling is approved.
The STA 202 and AP 204 then exchange data frames 216 via the tunnel. As discussed above, the tunnel relies on the first OTA device address to identify the station on the wireless network. Upon receiving a tunnel frame, the AP 204 is able to decrypt the contents of the packet as the STA 202 and AP 204 share key information exchanged during the 4-way handshake 210. Upon decrypting the contents of the tunnel frame, a second frame is identified by the AP. The second frame identifies the STA 202 via the stable device address. The AP 204 is then able to forward the embedded frame on (e.g., over the data network 106).
The STA then initiates an additional rotation of its device address, and transmits an action request message 218 requesting a new tunnel. The action request frame is sent identifying the STA view a second device address (“MAC2”). The AP 204 acknowledges the request by transmitting an action response frame 220. The action response frame 220 identifies the STA 202 via a destination address indicating the second device address.
After the action response frame 220 is received, a new tunnel is established between the STA 202 and the AP 204. The second OTA device address identifies the STA in a tunnel packet 222 sent to or from the STA 202. Encapsulated inside the tunneled frame is a second frame that identifies the STA 202 via the stable device address.
An association response frame has, in some embodiments, a frame body in accordance with the frame body 366 shown in
An action frame has, in some embodiments, a frame body in accordance with the frame body field 371 shown in
After deriving the PTK, the authenticator 382 generates an EAPOL-key message 387, indicating the supplicant 381 is to install the PTK. The EAPOL-key message 387 also includes a MIC, and the encrypted GTK (if applicable).
In response to receiving the EAPOL-key message 387, the supplicant 381 transmits an EAPOL-key message 388, which confirms that the EAPOL-key message 387 was received, and that the supplicant is installing the PTK. Each of the supplicant 381 and authenticator 382 then install the PTK in steps 389 and 390 respectively. The supplicant 381 also installs the GTK in step 389.
The network resource mapping table 395 includes a stable identifier field 396 and a network resource identifier field 397. The stable identifier field 396 stores an identifier that identifies a single wireless station. The stable identifier field 396 may be cross-referenced with the stable identifier field 393. Thus, some embodiments are able to identify one or more network resources associated with an OTA device address by first mapping the OTA device address to a stable identifier via the address mapping table 392, then mapping from the stable identifier to the network resource(s) via the network resource mapping table 395. A wireless device that is associated with multiple network resources may have multiple rows allocated in the network resource mapping table 395.
The STA 402 and AP 404 then perform a 4-way handshake 414. Once the 4-way handshake completes, the STA 402 and AP 404 are both in possession of a shared key, such as a pairwise master key, which is used to encrypt communications between the STA 402 and AP 404. Thus, the STA 402 is able to securely communicate, based on the shared key, an action request frame 416 to the AP 404. The action request frame 416 identifies the STA 402 via the first OTA device address, but also includes a stable device address (e.g., stable MAC) that also identifies the first device address. Thus, the action request frame 416 communicates a mapping between the first OTA device address and the stable device address. The AP 404 responds to the action request frame 416 with an action response frame 418. The action response frame acknowledges receipt of the mapping, and identifies the STA 402 via the first OTA device address. The STA 402 and AP 404 then perform data communications 420, again based on the shared key, via the first OTA device address. The AP 404 uses the mapping obtained from the action request frame 416 to identify the STA 402. For example, the AP 404 maintains a data structure that maps network services and/or resources used/needed by the STA 402 to the stable device address provided in the mapping. Upon receiving a frame from the STA via the first OTA device address, the AP 404 is able to identify those resources and/or services by translating from the received first OTA device address to the stable device address.
At a later time, the STA rotates its OTA device address from the first OTA device address to a second OTA device address. The STA 402 transmits a second action request frame 422. The second action request frame 422 identifies the STA 402 via the second OTA device address, which the AP 404 is able to map back to the stable device address since the second action request frame 422 also indicates the stable device address. Thus, upon receiving the second action request frame 422 from the STA 402, the AP 404 can map from the second OTA device address, to the stable device address, and to the network services and/or resources that are associated with the stable device address. The AP 404 generates an action response frame 424 that acknowledges processing of the second action request frame 422. The STA 402 and AP 404 are then able to perform encrypted data communications 426 via the second OTA device address, and the AP is able to associate these communications with services and/or network resources previously associated with the first OTA device address.
The STA 502 then initiates an association with the AP 504 via an association request message 512. The STA 502 is identified in the association request message 512 via a first OTA device address (e.g., “MAC1”). The association request message 512 includes the first OTA device address, in at least some embodiment, in a source address field of an 802.11 header of the association request message. The AP 504 responds to the association request message 512 via an association response message 514. The association response message 514 identifies the STA 502 as a destination of the association response message 514 via a destination address field in an 802.11 header of the association response message. The association response message 514 identifies the STA 502 via the first OTA device address. The association response message 514 indicates that the AP 504 is rejecting the association requested by the STA 502. The association response message 514 also indicates, in at least some embodiments, a wait time period before the STA 502 can attempt to associate with the AP 504. The AP 504 then initiates a SA-Query request 516 to the STA 502. The STA 502 responds to the SA-Query request 516 with a SA-Query response message 518. The SA-Query response message 518 indicates a mapping between the second OTA device address and a stable identifier or a reference device address. In some embodiments, the mapping is indicated in an information element of the SA-Query response message 518.
After providing the mapping to the AP 504, the STA 502 initiates a second association request message 520. The STA 502 is identified in the second association request message 520 via the second OTA device address (e.g., “MAC2”). The AP 504, as a result of the SA-Query response message 518, is able to map from the second OTA device address to the reference identifier or reference device address, and identify that the device transmitting the second association request message 520 is the STA 502. As a result of the ability of AP 504 to identify the STA 502, the AP 504 responds to the second association request message 520 with an association response message 522, which indicates a successful association.
The STA 502 and AP 504 then perform a 4-way handshake 524. After the 4-way handshake 524 is successful, the STA 502 and AP 504 perform data communications 526 based on the second OTA device address.
The STA 602 and AP 604 then perform a 4-way handshake 616, where each of the STA 602 and AP 604 obtain a shared key that can be used to perform encrypted communication 618 between the two devices. The encrypted communication 618 relies on the first OTA device address to identify the STA 602.
The STA 602 then transmits an Access Network Query Protocol (ANQP) request message 620 to the AP 604. The ANQP request indicates the first OTA device address in a source address field of an 802.11 header included in the ANQP request message 620. The ANQP request message also indicates a stable identifier of the STA 602. In some embodiments, the stable identifier is a stable device address, such as a station address assigned to the STA 602 by a manufacturer. Based on the ANQP request message 620, the AP 604 is able to establish a mapping between the first OTA device address and the stable identifier. The AP 604 responds with an ANQP response message 622. The ANQP response message addresses the STA 602 via the first device address, but also provides the STA 602 with a second OTA device address. The STA 602 then transmits an association request message 624 to the AP 604, and identifies itself in the message via the new second device address provided to the STA 602 by the AP 604 in the ANQP response message 622. The AP 604 responds to the association request message 624 with an association response message 626, and indicates the new second device address as a destination address field in the association response message 626.
The STA 602 and AP 604 then perform a 4-way handshake 628, with the STA 602 identified during the 4-way handshake 628 via the second OTA device address. Once the 4-way handshake 628 is complete, the STA 602 and AP 604 are able to perform data communication 630 over an encrypted channel via shared key information made available during the 4-way handshake 628.
After start operation 705, the method 700 moves to operation 710, where a first association is performed by a wireless client device (e.g., an STA). The association is with an AP. The association includes, in some embodiments, the wireless client device transmitting an association request message to the AP, and the AP responding with an association response message. The association request message identifies the wireless client device via a first OTA device address in a source address field of the association request message. The association response message identifies the wireless client device via the first OTA device address in a destination address field of the association response message.
The association, in some embodiments, establishes an association identifier (e.g. via association identifier field 369) that the wireless client device can utilize to identify its relationship with the AP. Some embodiments of operation 710 include receiving an association response message from the AP. The association response includes, in some embodiments, a status code field (e.g. status code field 368) indicating whether the association was successful. Some embodiments of operation 710 evaluate the status code field and condition further performance of method 700 on whether the association was successful.
After the association is complete, method 700 moves to operation 715, where a secure communications channel is established based on the association. In some embodiments, the secure communications channel is established via a 4-way handshake between the wireless client device and the AP. As described above, the 4-way handshake is a process of exchanging four messages between the AP (acting as an authenticator) and a client device (e.g., the wireless client device, acting as the supplicant). The 4-way handshake provides for generation of encryption keys that are used to establish the secure communications channel, as described above in connection with
In operation 720, a first mapping between the first device address and a stable device address is transmitted over the secure channel to the AP from the wireless client device. In some embodiments, the stable device address is a MAC address provided to the wireless client device by its manufacturer. In some embodiments, the first device address is a locally administrated station address. In some embodiments, the first mapping is transmitted to the AP via an action frame. In some embodiments, operation 720 includes generating the action frame so as to request a tunnel be established using the first OTA device address to identify the wireless client device, with the tunnel encapsulating a set of frames that identifies the wireless client device using the stable device address instead of the first OTA device address.
In operation 725, data communication with the AP is performed based on the mapping. For example, in some embodiments, the wireless client device utilizes the first device address as an OTA device address when communicating data with the AP. Thus, packets destined for the wireless client device from the AP include the first OTA device address as a destination address in the OTA packet. Packets destined for the AP from the wireless client device indicate the first OTA device address as a source address in these packets. In embodiments that rely on a tunneling solution for communication between the wireless client device and AP, operation 725 includes generating a first frame that identifies the wireless client device via the stable device address. The first frame, in some embodiments, is generated according to IEEE 802.3 standard frame format. The first frame is then encapsulated within a second frame, which identifies the wireless client device via the first OTA device address. In some embodiments, the second frame is generated in accordance with an IEEE 802.11 standard frame format. The second frame is then transmitted to the AP. In some embodiments of operation 725, a third frame is received from the AP, and decoded to de-encapsulate a fourth frame from the third frame. The third frame identifies the wireless client device via the first OTA device address, and complies, in some embodiments, with an 802.11 frame format, which is relied upon when it is decoded by operation 725. The fourth frame is decoded according to an 802.3 packet format, and identifies the station via the stable device address.
In operation 730, a second association between the wireless client device and the AP is performed. Operation 730 is similar, in some embodiments, to operation 710, except that the wireless client device utilizes a second OTA device address to identify itself to the AP instead of the first device address discussed above. Thus, at operation 730, the wireless client device has rotated its OTA device address from the first OTA device address to the second OTA device address.
In operation 735, a second secure channel is established based on the second association. In some embodiments, operation 735 is performed in a similar manner to that of operation 715, except that the station relies on the second OTA device address to identify itself instead of the first OTA device address relied upon in operation 715.
In operation 740, a second mapping is communicated over the second secure channel to the AP by the station. Operation 740 operates in a similar manner to operation 720, discussed above, except that the second mapping maps the second OTA device address to the stable device address, whereas the first mapping communication in operation 720 mapped the first OTA device address to the stable device address. In some embodiments, the second mapping is communicated to the AP via an action frame. In some embodiments, operation 720 includes generating an action frame that requests a tunnel be established using the second OTA device address, with the tunnel encapsulating a set of frames that identifies the station using the stable device address instead of either the first OTA device address or the second OTA device address.
In operation 742, second data communication are performed based on the second mapping. Thus, the second data communications identify the wireless client device using the second OTA device address. As discussed above, some embodiments of operation 742 include encapsulating a first frame (of operation 742) that identifies the wireless client device via the stable device address, within a second frame (of operation 742) that identifies the wireless client device via the second OTA device address. The second frame is then transmitted to the AP. Some embodiments of operation 742 include receiving a third frame (of operation 742) from the AP that identifies the wireless client device via the second OTA device address. Operation 742 then decodes the third frame to de-encapsulate or otherwise identify a fourth frame (of operation 742) that identifies the wireless client device based on the stable device address. In some embodiments, the third frame is decoded in conformance with an IEEE 802.11 frame format. A data payload of the fourth frame is then processed by the wireless client device as inbound network packet data. In some embodiments, the fourth frame is decoded in conformance with an IEEE 802.3 frame format.
After operation 740 completes, method 700 moves to end operation 744.
After start operation 755, method 750 moves to operation 760, where a first association is performed by a wireless client device. In some embodiments, operation 760 includes receiving an association request message from the wireless client device (e.g. including the frame body field 314 shown in
In operation 765, a secure communications channel is established with the wireless client device (that sent the association request). Similar to operation 715 discussed above with respect to method 700, some embodiments of operation 765 perform one side of a 4-way handshake with the wireless client device to establish the secure communications channel. The device performing the method 750 acts as an authenticator in the 4-way handshake, described above in connection with
In operation 770, a mapping of the first device address to a stable identifier, (e.g. a stable device address) is received over the secure channel. In some embodiments, operation 770 includes decoding an action frame to identify the mapping. In some embodiments, the mapping is included in an information element of the action frame (e.g. an information element in the elements field 374 shown in
In operation 775, data communication with the wireless client device is performed based on the first mapping. In some embodiments, operation 775 includes decoding a first frame received from the wireless client device over the secure communications channel to identify a second frame. In some embodiments, the first frame conforms to an 802.11 frame format and the second frame conforms to an 802.3 frame format.
Some embodiments of operation 775 further including encapsulating a third frame identifying the wireless client device via the stable device address in a fourth frame that identifies the wireless client device using the first OTA device address. In some embodiments, the mapping from the stable device address to the first OTA device address is accomplished by searching a data structure analogous to the address mapping table described above with respect to
In operation 780, a second association is performed with the wireless client device. The second association differs from the first association discussed above with respect to operation 760 in that the wireless client device is identified via a second OTA device address. Thus, the wireless client device has rotated its OTA device address between operation 775 and operation 780.
In operation 785, a second secure communications channel is established based on the second association performed in operation 780. Operation 785 is performed in a similar manner as operation 765, discussed above. For example, some embodiments of operation 785 include performing a 4-way handshake with the wireless client device to install a PTK.
In operation 790, a second mapping is received over the second secure communication channel. The second mapping maps the second OTA device address to the stable identifier or stable device address. Some embodiments store the second mapping in a data structure analogous to the address mapping table described above with respect to
In operation 792, second data communication is performed with the wireless client device based on the second mapping. Similar to the communications of operation 775, some embodiments of the method 700 include receiving a first frame from the wireless client device, the first frame identifying the wireless client device via the second OTA device address in a destination address field of the first frame. In these embodiments, operation 792 further includes decoding it to identify a second frame encapsulated with the first frame. The second frame identifies the wireless client device via the stable device address. Based on the stable device address of the second frame, the device executing the method 700 is able to identify network resources associated with the wireless client device, such as an IP address, infrastructure station address, public keys, or other network resources.
Some embodiments of operation 792 further include generating a third frame identifying the wireless client device via the stable device address (or receiving the first frame from another infrastructure component, such as a WLC or a firewall), and encapsulating the third frame in a fourth frame, that identifies the wireless client device via the second OTA device address. In some embodiments, the third frame is generated to comply with an 802.3 frame format while the fourth frame is generated to comply with an 802.11 frame format. The fourth frame is then transmitted over a wireless medium to the wireless client device.
After operation 792 completes, method 750 moves to end operation 794.
After start operation 805, method 800 moves to operation 810, where a first association request is transmitted to an access point. The association request identifies a wireless client device transmitting the first association request via a first OTA device address. In some embodiments, the association request includes the example of the frame body field 361 discussed above with respect to
In operation 815, an association response is received from the AP. The association response indicates the AP has rejected the association request transmitted in operation 810. In some embodiments, the rejection is indicated via a status code in the status code field 368 of frame body 366, discussed above with respect to
In operation 820, an SA-Query request is received from the AP. As discussed above with respect to
In response to the SA-Query request received in operation 820, operation 825 transmits a SA-Query response message. The SA-Query response message indicates a mapping from the first OTA device address to a stable identifier or stable device address. As discussed above with respect to
In operation 840, a second association request is transmitted to the AP. The second association request identifies the wireless client device via the first OTA device address. Similar to the association request of operation 810, the second association request includes, in some embodiments, a frame body formatted according to the example of the frame body field 371 discussed above with respect to
In operation 845, a second response to the second association request is received. The second response indicates that the second association request succeeded in forming an association with the AP (e.g. via the status code field 368). Some embodiments of method 800 then communicate with the AP based on the successful association. For example, some embodiments perform a 4-way handshake with the AP based on the successful association, which provides a secure communication channel with the AP. The wireless client device is then able to exchange data with the AP over the secure communications channel.
After operation 845 completes, method 800 moves to end operation 848.
After start operation 855, method 850 moves to operation 860, where a first association request is received from a wireless client device. The wireless client device is identified via a first OTA device address in a source address field of the first association request (e.g. the source address field 308). In some embodiments, the association request message includes a frame body field (e.g. frame body field 314) formatted in a manner consistent with the example of the frame body field 371, discussed above with respect to
In operation 865, the association request is rejected. Rejecting the association request includes, in at least some embodiments, transmitting an association response message to the wireless client device, the association response indicating the rejection. In some embodiments, the rejection is based on the use of the first OTA device address in the association request of operation 860. For example, in some embodiments, operation 860 checks or searches a data store that records data associated with an OTA device address (such as a mapping between the OTA device address and a stable device address). When there is a failure to identify any such records, and thus no information or mapping is found, the association request is rejected, at least in some embodiments. The rejection is indicated, in some embodiments, in a status field of an association response sent to the wireless client device.
Operation 870 transmits to the wireless client device, and based on the rejection of the association request, an SA-Query request message. As discussed above with respect to
In operation 875, an SA-Query response message is received from the wireless client device. The SA-Query response message is also an action frame having a particular predefined category field value, at least in some embodiments. In operation 880, the SA-Query response message is parsed or otherwise decoded to obtain a mapping from the first OTA device address to a stable device address. For example, as discussed above with respect to the example frame body field 371 of an action frame, some embodiments decode an information element from the elements field 374, and obtain a mapping (e.g., represented by temp device address field 377 and stable device address field 378).
In operation 885, the mapping obtained from the action frame is stored for use in communication with the wireless client device. In particular the mapping is used to identify the wireless client device based on a message that utilizes the first OTA device address to identify the wireless client device. Via the mapping, a device performing the method 850 is able to identify a common wireless client device responsible for sending packets that identify the wireless client device using two or more different OTA device addresses. Some embodiments store the mapping in a data structure analogous to the address mapping table, discussed above with respect to
In operation 890, a second association request is received from the wireless client device. The wireless client device is identified by the second association request via a source address field that stores the first OTA device address. In some embodiments, operation 890 searches previously stored mappings for the first OTA device address based on it being indicated in the source address field. If a mapping for the device address is found, the device performing the method 800 is able to translate from the OTA device address used in the second association request to a stable identifier, such as a stable device address, that identifies a unique device attempting the association (e.g. the wireless client device).
In operation 892, the second association request is accepted. Accepting the second association request includes, in at least some embodiments, transmitting an association response message to the wireless client device, with the association response message indicating the association is accepted (e.g., via the status code field 368). Operation 892 indicates, in some embodiments, an association identifier for the successful association in the association response message (e.g., via the association identifier field 369 in some embodiments.
After operation 892, method 850 moves to end operation 894.
In at least one embodiment, the device 900 includes hardware processing circuitry such as one or more processor(s) 902, one or more memory element(s) 904, storage 906, a bus 908, one or more network processor unit(s) 910 interconnected with one or more network input/output (I/O) interface(s) 912, one or more I/O interface(s) 914, and control logic 920. In various embodiments, instructions associated with logic for device 900 can overlap in any manner and are not limited to the specific allocation of instructions and/or operations described herein.
In at least one embodiment, processor(s) 902 is/are at least one hardware processor configured to execute various tasks, operations and/or functions for device 900 as described herein according to software and/or instructions configured for device 900. Processor(s) 902 (e.g., a hardware processor) can execute any type of instructions associated with data to achieve the operations detailed herein. In one example, processor(s) 902 can transform an element or an article (e.g., data, information) from one state or thing to another state or thing. Any of potential processing elements, microprocessors, digital signal processor, baseband signal processor, modem, physical layer (PHY), controllers, systems, managers, logic, and/or machines described herein can be construed as being encompassed within the broad term ‘processor’.
In at least one embodiment, memory element(s) 904 and/or storage 906 is/are configured to store data, information, software, and/or instructions associated with device 900, and/or logic configured for memory element(s) 904 and/or storage 906. For example, any logic described herein (e.g., control logic 920) can, in various embodiments, be stored for device 900 using any combination of memory element(s) 904 and/or storage 906. Note that in some embodiments, storage 906 can be consolidated with memory element(s) 904 (or vice versa), or can overlap/exist in any other suitable manner.
In at least one embodiment, bus 908 can be configured as an interface that enables one or more elements of device 900 to communicate in order to exchange information and/or data. Bus 908 can be implemented with any architecture designed for passing control, data and/or information between processors, memory elements/storage, peripheral devices, and/or any other hardware and/or software components that may be configured for device 900. In at least one embodiment, bus 908 may be implemented as a fast kernel-hosted interconnect, potentially using shared memory between processes (e.g., logic), which can enable efficient communication paths between the processes.
In various embodiments, network processor unit(s) 910 may enable communication between device 900 and other systems, devices, or entities, via network I/O interface(s) 912 (wired and/or wireless) to facilitate operations discussed for various embodiments described herein. In various embodiments, network processor unit(s) 910 can be configured as a combination of hardware and/or software, such as one or more Ethernet driver(s) and/or controller(s) or interface cards, Fibre Channel (e.g., optical) driver(s) and/or controller(s), wireless receivers/transmitters/transceivers, baseband processor(s)/modem(s), and/or other similar network interface driver(s) and/or controller(s) now known or hereafter developed to enable communications between device 900 and other systems, devices, or entities to facilitate operations for various embodiments described herein. In various embodiments, network I/O interface(s) 912 can be configured as one or more Ethernet port(s), Fibre Channel ports, any other I/O port(s), and/or antenna(s)/antenna array(s) now known or hereafter developed. Thus, the network processor unit(s) 910 and/or network I/O interface(s) 912 may include suitable interfaces for receiving, transmitting, and/or otherwise communicating data and/or information in a network environment.
I/O interface(s) 914 allow for input and output of data and/or information with other entities that may be connected to device 900. For example, I/O interface(s) 914 may provide a connection to external devices such as a keyboard, keypad, a touch screen, and/or any other suitable input and/or output device now known or hereafter developed. This may be the case, in particular, when the device 900 serves as a user device described herein. In some instances, external devices can also include portable computer readable (non-transitory) storage media such as database systems, thumb drives, portable optical or magnetic disks, and memory cards. In still some instances, external devices can be a mechanism to display data to a user, such as, for example, a computer monitor, a display screen, such as display, particularly when the device 900 serves as a user device as described herein.
In various embodiments, control logic 920 can include instructions that, when executed, cause processor(s) 902 to perform operations, which can include, but not be limited to, providing overall control operations of computing device; interacting with other entities, systems, etc. described herein; maintaining and/or interacting with stored data, information, parameters, etc. (e.g., memory element(s), storage, data structures, databases, tables, etc.); combinations thereof; and/or the like to facilitate various operations for embodiments described herein. [moo] The programs described herein (e.g., control logic 920) may be identified based upon application(s) for which they are implemented in a specific embodiment. However, it should be appreciated that any particular program nomenclature herein is used merely for convenience; thus, embodiments herein should not be limited to use(s) solely described in any specific application(s) identified and/or implied by such nomenclature.
[owl] In various embodiments, entities as described herein may store data/information in any suitable volatile and/or non-volatile memory item (e.g., magnetic hard disk drive, solid state hard drive, semiconductor storage device, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM), application specific integrated circuit (ASIC), etc.), software, logic (fixed logic, hardware logic, programmable logic, analog logic, digital logic), hardware, and/or in any other suitable component, device, element, and/or object as may be appropriate. Any of the memory items discussed herein should be construed as being encompassed within the broad term ‘memory element’. Data/information being tracked and/or sent to one or more entities as discussed herein could be provided in any database, table, register, list, cache, storage, and/or storage structure: all of which can be referenced at any suitable timeframe. Any such storage options may also be included within the broad term ‘memory element’ as used herein.
Note that in certain example implementations, operations as set forth herein may be implemented by logic encoded in one or more tangible media that is capable of storing instructions and/or digital information and may be inclusive of non-transitory tangible media and/or non-transitory computer readable storage media (e.g., embedded logic provided in: an ASIC, digital signal processing (DSP) instructions, software [potentially inclusive of object code and source code], etc.) for execution by one or more processor(s), and/or other similar machine, etc. Generally, memory element(s) 904 and/or storage 906 can store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof, and/or the like used for operations described herein. This includes memory element(s) 904 and/or storage 906 being able to store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof, or the like that are executed to carry out operations in accordance with teachings of the present disclosure.
In some instances, software of the present embodiments may be available via a non-transitory computer useable medium (e.g., magnetic or optical mediums, magneto-optic mediums, CD-ROM, DVD, memory devices, etc.) of a stationary or portable program product apparatus, downloadable file(s), file wrapper(s), object(s), package(s), container(s), and/or the like. In some instances, non-transitory computer readable storage media may also be removable. For example, a removable hard drive may be used for memory/storage in some implementations. Other examples may include optical and magnetic disks, thumb drives, and smart cards that can be inserted and/or otherwise connected to a computing device for transfer onto another computer readable storage medium.
Embodiments described herein may include one or more networks, which can represent a series of points and/or network elements of interconnected communication paths for receiving and/or transmitting messages (e.g., packets of information) that propagate through the one or more networks. These network elements offer communicative interfaces that facilitate communications between the network elements. A network can include any number of hardware and/or software elements coupled to (and in communication with) each other through a communication medium. Such networks can include, but are not limited to, any local area network (LAN), virtual LAN (VLAN), wide area network (WAN) (e.g., the Internet), software defined WAN (SD-WAN), wireless local area (WLA) access network, wireless wide area (WWA) access network, metropolitan area network (MAN), Intranet, Extranet, virtual private network (VPN), Low Power Network (LPN), Low Power Wide Area Network (LPWAN), Machine to Machine (M2M) network, Internet of Things (IoT) network, Ethernet network/switching system, any other appropriate architecture and/or system that facilitates communications in a network environment, and/or any suitable combination thereof.
Networks through which communications propagate can use any suitable technologies for communications including wireless communications (e.g., 4G/5G/nG, Institute of Electrical and Electronics Engineers (IEEE) 802.11 (e.g., Wi-Fi®/Wi-Fib®), IEEE 802.15 (e.g. Wireless Personal Area Networks (WPAN)), IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), Radio-Frequency Identification (RFID), Near Field Communication (NFC), Bluetooth™, millimeter (mm).wave, Ultra-Wideband (UWB), etc.), and/or wired communications (e.g., T1 lines, T3 lines, digital subscriber lines (DSL), Ethernet, Fibre Channel, etc.). Generally, any suitable means of communications may be used such as electric, sound, light, infrared, and/or radio to facilitate communications through one or more networks in accordance with embodiments herein. Communications, interactions, operations, etc. as discussed for various embodiments described herein may be performed among entities that may directly or indirectly connected utilizing any algorithms, communication protocols, interfaces, etc. (proprietary and/or non-proprietary) that allow for the exchange of data and/or information.
Communications in a network environment can be referred to herein as ‘messages’, ‘messaging’, ‘signaling’, ‘data’, ‘content’, ‘objects’, ‘requests’, ‘queries’, ‘responses’, ‘replies’, etc. which may be inclusive of packets. As referred to herein and in the claims, the term ‘packet’ may be used in a generic sense to include packets, frames, segments, datagrams, and/or any other generic units that may be used to transmit communications in a network environment. Generally, a packet is a formatted unit of data that can contain control or routing information (e.g., source and destination address, source and destination port, etc.) and data, which is also sometimes referred to as a ‘payload’, ‘data payload’, and variations thereof. In some embodiments, control or routing information, management information, or the like can be included in packet fields, such as within header(s) and/or trailer(s) of packets. Internet Protocol (IP) addresses discussed herein and in the claims can include any IP version 4 (IPv4) and/or IP version 6 (IPv6) addresses.
To the extent that embodiments presented herein relate to the storage of data, the embodiments may employ any number of any conventional or other databases, data stores or storage structures (e.g., files, databases, data structures, data or other repositories, etc.) to store information.
Note that in this Specification, references to various features (e.g., elements, structures, nodes, modules, components, engines, logic, steps, operations, functions, characteristics, etc.) included in ‘one embodiment’, ‘example embodiment’, ‘an embodiment’, ‘another embodiment’, ‘certain embodiments’, ‘some embodiments’, ‘various embodiments’, ‘other embodiments’, ‘alternative embodiment’, and the like are intended to mean that any such features are included in one or more embodiments of the present disclosure, but may or may not necessarily be combined in the same embodiments. Note also that a module, engine, client, controller, function, logic or the like as used herein in this Specification, can be inclusive of an executable file comprising instructions that can be understood and processed on a server, computer, processor, machine, compute node, combinations thereof, or the like and may further include library modules loaded during execution, object files, system files, hardware logic, software logic, or any other executable modules.
It is also noted that the operations and steps described with reference to the preceding figures illustrate only some of the possible scenarios that may be executed by one or more entities discussed herein. Some of these operations may be deleted or removed where appropriate, or these steps may be modified or changed considerably without departing from the scope of the presented concepts. In addition, the timing and sequence of these operations may be altered considerably and still achieve the results taught in this disclosure. The preceding operational flows have been offered for purposes of example and discussion. Substantial flexibility is provided by the embodiments in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be provided without departing from the teachings of the discussed concepts.
As used herein, unless expressly stated to the contrary, use of the phrase ‘at least one of’, ‘one or more of’, ‘and/or’, variations thereof, or the like are open-ended expressions that are both conjunctive and disjunctive in operation for any and all possible combination of the associated listed items. For example, each of the expressions ‘at least one of X, Y and Z’, ‘at least one of X, Y or Z’, ‘one or more of X, Y and Z’, ‘one or more of X, Y or Z’ and ‘X, Y and/or Z’ can mean any of the following: 1) X, but not Y and not Z; 2) Y, but not X and not Z; 3) Z, but not X and not Y; 4) X and Y, but not Z; 5) X and Z, but not Y; 6) Y and Z, but not X; or 7) X, Y, and Z.
Additionally, unless expressly stated to the contrary, the terms ‘first’, ‘second’, ‘third’, etc., are intended to distinguish the particular nouns they modify (e.g., element, condition, node, module, activity, operation, etc.). Unless expressly stated to the contrary, the use of these terms is not intended to indicate any type of order, rank, importance, temporal sequence, or hierarchy of the modified noun. For example, ‘first X’ and ‘second X’ are intended to designate two ‘X’ elements that are not necessarily limited by any order, rank, importance, temporal sequence, or hierarchy of the two elements. Further as referred to herein, ‘at least one of’ and ‘one or more of can be represented using the’(s)′ nomenclature (e.g., one or more element(s)).
In one form, an method is provided comprising: associating with a wireless client device, the wireless client device identified via a first device address; establishing, based on the associating, a first secure communication channel with the wireless client device; receiving, over the first secure communication channel, a first mapping of the first device address to a stable device address; performing first data communication with the wireless client device based on the first mapping; second associating with the wireless client device, the wireless client device identified via a second device address; establishing a second secure communication channel with the wireless client device; receiving, over the second secure communication channel, a second mapping of the second device address to the stable device address; and performing second data communication with the wireless client device based on the second mapping.
In another form, an apparatus is provided comprising: a network interface configured to enable network communications; one or more processors; and one or more memories storing instructions that when executed configure the one or more processors to perform operations comprising: associating with a wireless client device, the wireless client device identified via a first device address; establishing, based on the associating, a first secure communication channel with the wireless client device; receiving, over the first secure communication channel, a first mapping of the first device address to a stable device address; performing first data communication with the wireless client device based on the first mapping; second associating with the wireless client device, the wireless client device identified via a second device address; establishing a second secure communication channel with the wireless client device; receiving, over the second secure communication channel, a second mapping of the second device address to the stable device address; and performing second data communication with the wireless client device based on the second mapping.
In still another form, a method is provided comprising: receiving, from a wireless client device, an association request to associate to a wireless network, the wireless client device identified by the association request via a first device address; rejecting, based on the first device address, the association request; transmitting, to the wireless client device, and based on the rejecting, a security association (SA)-query request message; receiving, from the wireless client device, a SA-query response message; decoding the SA-query response message to identify a mapping of the first device address to a stable device address; storing the mapping; receiving, from the wireless client device, a second association request, the wireless client device identified by the second association request via the first device address; and accepting, based on the stored mapping, the second association request.
The methods presented herein may be embodied in a non-transitory computer readable storage medium comprising instructions that when executed configure one or more processors to perform the operations of the method.
One or more advantages described herein are not meant to suggest that any one of the embodiments described herein necessarily provides all of the described advantages or that all the embodiments of the present disclosure necessarily provide any one of the described advantages. Numerous other changes, substitutions, variations, alterations, and/or modifications may be ascertained to one skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and/or modifications as falling within the scope of the appended claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 10237738 | Lee et al. | Mar 2019 | B2 |
| 10454887 | Weis et al. | Oct 2019 | B2 |
| 10820202 | Gundavelli | Oct 2020 | B1 |
| 20120213211 | Remaker | Aug 2012 | A1 |
| 20140064184 | Cherian | Mar 2014 | A1 |
| 20150063205 | Elliott | Mar 2015 | A1 |
| 20160135041 | Lee | May 2016 | A1 |
| 20160261602 | Glassco | Sep 2016 | A1 |
| 20160269359 | Adrangi et al. | Sep 2016 | A1 |
| 20160302058 | Mestanov et al. | Oct 2016 | A1 |
| 20170142064 | Weis et al. | May 2017 | A1 |
| 20170208002 | Bittles | Jul 2017 | A1 |
| 20180324142 | Adrangi et al. | Nov 2018 | A1 |
| 20190238501 | Chuu | Aug 2019 | A1 |
| 20190386955 | Weis et al. | Dec 2019 | A1 |
| 20200244655 | Gundavelli et al. | Jul 2020 | A1 |
| 20210036988 | McKibben et al. | Feb 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 102015204210 | Sep 2016 | DE |
| 1379029 | Jan 2004 | EP |
| 1732265 | Dec 2006 | EP |
| 2016114843 | Jul 2016 | WO |
| 2020000430 | Jan 2020 | WO |
| 2020010126 | Sep 2020 | WO |
| Entry |
|---|
| Ansley et al., “Proposal for New Action Frame to Aid Mac Randomization Handling,” IEEE 802.11-19/0179r3, Jul. 2019, 9 pages. |
| Marks, “IEEE Std 802c: What's New and Useful in the Overview and Architecture,” IEEE 802.1 Contribution, Sep. 2017, 42 pages. |
| Slashdot, “Did MacOS Stop Allowing Changes to Wifi MAC Addresses?,” https://mobile.slashdot.org/story/19/10/06/177216/did-macos-stop-allowing-changes-to-wifi-mac-addresses, Apr. 5, 2021, 8 pages. |
| Volz, et al., “Link-Layer Addresses Assignment Mechanism for DHCPv6,” draft-bvtm-dhc-mac-assign-02, Dynamic Host Configuration (DHC), Internet-Draft, Oct. 20, 2018, 18 pages. |
| Lee, et al., “Problem Statements for MAC Address Randomization,” draft-lee-randomized-macaddr-ps-01 Internet Engineering Task Force, Internet-Draft, Sep. 22, 2020, 6 pages. |
| Ansley, “IEEE P802.11—Randomized and Changing MAC Address (RCM) Study Group (SG)—Meeting Update,” https://www.ieee802.org/11/Reports/rcmtig_update.htm, Apr. 5, 2021, 2 pages. |
| Stretch, “MAC Address Aggregation and Translation as an Alternative to L2 Overlays,” https://packetlife.net/blog/2014/nov/18/mac-address-aggregation-and-translation/, Nov. 18, 2014, 9 pages. |
| Wang, et al., “MAC Address Translation for Enabling Scalable Virtual Private LAN Services?,” 21st International Conference on Advanced Information Networking and Applications Workshops (AINAW'07), May 2007, 6 pages. |
| Android Open Source Project, “Privacy: MAC Randomization,” retrieved from https://source.android.com/devices/tech/connect/wifi-mac-randomization, on Dec. 4, 2020, 4 pages. |
| Bellovin et al., “Privacy-Enhanced Searches Using Encrypted Bloom Filters,” Columbia University Computer Science Technical Reports, CUCS-034-07, Apr. 27, 2011, 16 pages. |
| Razaque, et al., “Restoring the privacy and confidentiality of users over Mobile collaborative learning (MCL) environment,” IEEE Transaction Latin America, vol. 9, No. 7, Dec. 2011, 13 pages. |
| Alibaba Cloud, “The principle of Arp-nat (MAC Address translation),” https://topic.alibabacloud.com/a/the-principle-of-arp-nat-mac-address-translation_8_8_30147619.html, Nov. 2017, 7 pages. |
| Wi-Fi Alliance, “WPA3™ Specification,” Version 3, WPA3™ Specification Version 3.0, https://www.wi-fi.org/file/wpa3-specification, Dec. 20, 2019, 30 pages. |
| Michael Montemurro, “MAC Address Change,” IEEE P802.11, Wireless LANs, doc.: IEEE 802.11-19/2024r1, Nov. 11, 2019, 4 pages. |
| “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications—Amendment 5: Preassociation Discovery,” IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements, IEEE Computer Society, IEEE Std 802.11aq™-2018, Jun. 14, 2018, 69 pages. |
| International Search Report and Written Opinion in International Application No. PCT/US2021/031684, dated Jul. 5, 2021, 16 pages. |
| Frank Ciotti, et al., “TGi Dallas Interim Meeting Minutes—Jan. 2002,” LinCom Wireless, Wireless LANs, doc.: IEEE 802.11-02/028r0, Jan. 21-25, 2002, 34 pages. |
| “Amendment 2: Local Medium Access Control (MAC) Address Usage,” IEEE Standards Association, IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, IEEE Std 802c™-2017, 26 pages. |
| “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications—Amendment 6: Medium Access Control (MAC) Security Enhancements,” IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks Specific requirements, IEEE Std 802.11i™-2004, Jul. 23, 2004, 190 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20220361269 A1 | Nov 2022 | US |
