Mechanisms for protecting fronthaul links from man-in-the-middle (MITM) attacks

Abstract

In a network communication system, a method for protecting a fronthaul link from man-in-the-middle (MiTM) attacks, the method comprising: The method includes receiving an authentication request for port authentication from the supplicant via an Ethernet frame through a port of the authenticator; obtaining, by the authenticator, a hop count from the Ethernet frame corresponding to the number of hops in a transmission path of the Ethernet frame between the supplicant and the authenticator; comparing the hop count with a predetermined threshold to determine whether the port should be disabled; and disabling the port based on the hop count being greater than the predetermined threshold.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to Indian Provisional Application No. 202241019649, filed on March 31, 2022, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Apparatus and methods consistent with example embodiments of the present disclosure relate to wireless communications, and in particular to mechanisms for protecting fronthaul links from man-in-the-middle (MiTM) attacks. [Background technology]

[0003] Traditionally, a man-in-the-middle (MiTM) attack is a general term for a criminal who is in the middle of a communication session between a user (e.g., a supplicant) and an application (e.g., an authenticator). The criminal attacks the interaction by eavesdropping or impersonating one of the parties, making the communication session between the criminal and the application appear as a normal exchange of information. The goal of the attack may be to steal personal information such as login credentials, account information, and credit card numbers, as an example. Criminals may target supplicants for financial applications, corporate websites, e-commerce websites, and other websites that require logins. Criminals may use the information obtained during the attack to commit acts such as identity theft, fraudulent fund transfers, and unauthorized password changes.

[0004] Prior to communication, the supplicant (10) must complete port authentication with the authenticator (30) (e.g., using 802.1x port authentication, etc.) based on information in the authentication server (40). However, as part of the authentication process, a rogue bridge / entity (20) may intervene as a man-in-the-middle (MiTM) (60) between the supplicant (10) and the authenticator (30), i.e., between the supplicant (10) and the authenticator (30). The rogue entity (20) waits for the port to be authenticated and then launches an attack (e.g., a MiTM attack).

[0005] The unauthorized entity (20) can be a rogue switch, a rogue bridge, etc., as shown in Figure 1. Specifically, the unauthorized entity (20) connects to a port on the authenticator (30) to transmit data. However, the port must be opened before any data can be transmitted. That is, port authentication must be considered successful in order to open the port and begin transmitting data. The supplicant (10) connects to the unauthorized entity (20) assuming that the unauthorized entity (20) is the authenticator (30) (e.g., a switch with authentication capabilities) and initiates 802.1x authentication with the unauthorized entity (20). For example, instead of sending a request to the authenticator (30), the supplicant (10) sends an authentication request to the rogue switch. The unauthorized entity (20) then forwards packets (e.g., authentication requests) to the actual authenticator (30) during authentication. If authentication is successful, the port is opened on the authenticator (30). As a result, the MiTM (60) can use the unauthorized entity (20) to send and receive packets to and from the network (50) (e.g., a cellular network, a cloud network, a wireless network, etc.) through the port. Thus, the MiTM attack is initiated after the port is opened.

[0006] Alternatively, a MiTM attack may be performed by a person via a terminal device (e.g., phone, computer, etc.) as a MiTM (60), as shown in Figure 2. The attacker's terminal device acts as the unauthorized entity itself and connects to a port on the authenticator (30) without a malicious switch / bridge. The terminal device forwards packets to and from the authenticator (30). If authentication is successful, a port on the authenticator's (30) switch opens and can be used by the MiTM (60) (i.e., the terminal device) to launch attacks on and packet spoofing from the network (40).

[0007] It would therefore be desirable to address the above-mentioned disadvantages or other shortcomings, or to provide a useful alternative to protecting fronthaul links from MiTM attacks. Summary of the Invention [Means for solving the problem]

[0008] According to embodiments, a system and method are provided for protecting a fronthaul link from man-in-the-middle (MiTM) attacks. According to an embodiment, a method implemented by at least one processor for protecting a fronthaul link from a man-in-the-middle (MiTM) attack in a network communication system includes: receiving an authentication request for port authentication from a supplicant via an Ethernet frame through a port of an authenticator; obtaining, by the authenticator, from the Ethernet frame a hop count corresponding to the number of hops in a transmission path of the Ethernet frame between the supplicant and the authenticator; comparing the hop count with a predetermined threshold to determine whether to disable the port; and disabling the port based on the hop count being greater than the predetermined threshold.

[0009] The predetermined threshold is configured on the authenticator's port, where the port is an L2 interface.

[0010] The hop count is obtained from the header of the Ethernet frame.

[0011] The header of an Ethernet frame includes a 6-byte preamble and a 1-byte hop count field in which the hop count is recorded.

[0012] The hop count field is between the preamble and the Start Frame Delimiter (SFD) field.

[0013] The hop count is incremented within the Ethernet frame by any device along the transmission path.

[0014] The port authentication is IEEE802.1x port authentication.

[0015] According to an embodiment, an apparatus for protecting a fronthaul link from man-in-the-middle (MiTM) attacks in a network communication system includes: a memory for storing instructions; and at least one processor configured to receive an authentication request for port authentication from a supplicant via an Ethernet frame through a port of an authenticator; obtain, by the authenticator, from the Ethernet frame a hop count corresponding to a number of hops in a transmission path of the Ethernet frame between the supplicant and the authenticator; compare the hop count with a predetermined threshold to determine whether to disable the port; and execute instructions to disable the port based on the hop count being greater than the predetermined threshold.

[0016] The predetermined threshold is configured on the authenticator's port, where the port is an L2 interface.

[0017] The hop count is obtained from the header of the Ethernet frame.

[0018] The header of an Ethernet frame includes a 6-byte preamble and a 1-byte hop count field in which the hop count is recorded.

[0019] The hop count field is between the preamble and the start frame identifier (SFD) field.

[0020] The hop count is incremented within the Ethernet frame by any device along the transmission path.

[0021] The port authentication is IEEE802.1x port authentication.

[0022] According to an embodiment, a non-transitory computer-readable storage medium having stored thereon instructions executable by at least one processor to implement a method for protecting a fronthaul link from a man-in-the-middle (MiTM) attack in a network communication system, the method including: receiving an authentication request for port authentication from a supplicant via an Ethernet frame through a port of an authenticator; obtaining, by the authenticator, from the Ethernet frame a hop count corresponding to the number of hops in a transmission path of the Ethernet frame between the supplicant and the authenticator; comparing the hop count with a predetermined threshold to determine whether to disable the port; and disabling the port based on the hop count being greater than the predetermined threshold.

[0023] The predetermined threshold is configured on the authenticator's port, where the port is an L2 interface.

[0024] The hop count is obtained from the header of the Ethernet frame.

[0025] The header of an Ethernet frame includes a 6-byte preamble and a 1-byte hop count field in which the hop count is recorded, the hop count field being located between the preamble and the start frame identifier (SFD) field.

[0026] The hop count is incremented within the Ethernet frame by any device along the transmission path.

[0027] The port authentication is IEEE802.1x port authentication.

[0028] Therefore, embodiments herein disclose a mechanism for protecting fronthaul links from Man-in-the-Middle (MiTM) attacks by detecting unauthorized entities of MiTM attacks at the Ethernet layer in authentication scenarios (e.g., 802.1x port authentication). MiTM is where an unauthorized entity connects between a supplicant and an authenticator with or without the use of an unauthorized entity (e.g., a rogue bridge).

[0029] In one embodiment, the method includes detecting that a fraudulent entity is in place (e.g., when the fraudulent entity communicates with the authenticator to initiate the authentication process) and, upon detection, disabling the port as a preventative measure.

[0030] In one embodiment, the method includes preventing MiTM attacks by using hop counting in the Ethernet layer during authentication (eg, 802.1x port authentication).

[0031] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be realized by practice of the presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0032] The present invention is illustrated in the accompanying drawings, in which like reference characters indicate corresponding parts of the various views throughout. Embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0033] [Figure 1] This shows a related technique of a MiTM attack using a rogue switch / bridge. [Figure 2] This shows a related technique for a MiTM attack that does not use a malicious switch / bridge. [Figure 3] 1 shows an Ethernet header and frame according to the prior art. [Figure 4] 1 illustrates an Ethernet header format with a hop count to prevent MiTM attacks, according to embodiments disclosed herein. [Figure 5] 1 illustrates an Ethernet frame flow using hop counting to prevent MiTM attacks, according to embodiments disclosed herein. [Figure 6] 1 is a flowchart of an example process for protecting a fronthaul link from a man-in-the-middle (MiTM) attack, according to an example embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0034] The following detailed description of the exemplary embodiments refers to the accompanying drawings, in which the same reference numbers in different drawings may identify the same or similar elements.

[0035] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, in the flowcharts and descriptions of operations provided below, it will be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) concurrently, and the order of one or more operations may be permuted.

[0036] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Accordingly, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0037] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, in the disclosure of possible implementations, each dependent claim includes in combination with every other claim in the set of claims.

[0038] No element, act, or instruction used herein should be construed as critical or required unless explicitly described as such. Additionally, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Additionally, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" and "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0039] The embodiments herein and their various features and advantageous details will be more fully described with reference to the non-limiting embodiments shown in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted to avoid unnecessarily obscuring the embodiments herein. Furthermore, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments may be combined with one or more other embodiments to form new embodiments. As used herein, the term "or" refers to a non-exclusive or unless otherwise specified. The examples used herein are intended only to facilitate understanding of how the embodiments herein can be implemented and to further enable those skilled in the art to implement the embodiments herein. Therefore, the examples should not be construed as limiting the scope of the embodiments herein.

[0040] As is conventional in the art, embodiments may be described and illustrated in terms of blocks that perform one or more described functions. These blocks, sometimes referred to herein as units, modules, or the like, may be physically implemented by analog or digital circuits, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, and the like, and may optionally be driven by firmware. The circuits may be embodied, for example, in one or more semiconductor chips or on a substrate support, such as a printed circuit board. The circuits making up the blocks may be implemented by dedicated hardware, by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware for performing some functions of the block and a processor for performing other functions of the block. Each block of an embodiment may be physically separated into two or more interacting individual blocks without departing from the scope of the present invention. Similarly, the blocks of an embodiment may be physically combined into more complex blocks without departing from the scope of the present invention.

[0041] It should be understood that the accompanying drawings are used to help facilitate understanding of various technical features, and the embodiments presented herein are not limited by the accompanying drawings. Accordingly, the present disclosure should be construed to cover any modifications, equivalents, and alternatives in addition to those specifically described in the accompanying drawings.

[0042] Exemplary embodiments of the present disclosure provide methods and systems for protecting fronthaul links from man-in-the-middle (MiTM) attacks using unauthorized entities in Ethernet layer authentication (e.g., 802.1x port authentication). MiTM attacks can occur when an unauthorized entity connects between a supplicant and an authenticator with or without the use of an unauthorized device (e.g., a rogue bridge).

[0043] Referring now to the drawings, and more particularly to FIGS. 4-5, an exemplary embodiment of the present disclosure is shown.

[0044] FIG. 4 illustrates an Ethernet header format (400) with a hop count used to prevent MiTM attacks, according to some embodiments. The Ethernet header format (400) includes a 6-byte preamble rather than the traditional 7 bytes shown in FIG. 3. The header format also includes a 1-byte hop count, a 1-byte starting frame identifier (SFD), a 6-byte destination address, a 6-byte source address, a 2-byte length, a data range (45-1500 bytes), and a 4-byte frame check sequence (CRC). Thus, formatting the header to utilize a 6-byte preamble allows for the implementation of a 1-byte hop count. As a result, the hop count advantageously serves as a safeguard against MiTM attacks.

[0045] For example, during the authentication process, the supplicant (10) sends an authentication request to the authenticator (30) via Ethernet frame(s). The hop count in the Ethernet frame(s) is used to detect additional hops at the L2 layer if the Ethernet frame(s) is transmitted through the network (50) using a rogue entity (20) or man-in-the-middle device (60). Rogue entities may include rogue switches, rogue bridges, etc. The Ethernet frame(s) is 64 bytes, and the hop count is 1 byte long, with a value between 0 and 255. The hop count is derived from a 7-byte preamble that consumes 1 byte, i.e., 8 bits, and may be assigned a value range between 0 and 255. That is, the preamble may be shortened to 6 bytes, and a 1-byte hop count may be added to the end of the preamble. The hop count may be provided after the preamble and before the SFD, as shown in FIG. 4.

[0046] In some embodiments, the hop count may start at a value of 0 from the beginning of the Ethernet frame(s). Any switch / bridge / hub that consumes the Ethernet frame(s) and forwards / broadcasts packets may increment the hop count value. Any end entity / device, such as an authenticator (30), router, gateway, or system that consumes or modifies the Ethernet frame(s), may check the hop count in the Ethernet frame(s) and compare it to a minimum value. According to some embodiments, the minimum value may represent a predetermined threshold configured by a network administrator, security administrator, etc. based on the topology of the network (50).

[0047] In some embodiments, if the hop count value in the frame is greater than a set minimum predetermined threshold, the authenticator (30) can disable the port. A larger hop count value indicates the possible presence of an MiTM entity or some external rogue entity involved in transmitting data and ultimately incrementing the hop count. Therefore, the authenticator (30) disables the port as a precaution to prevent and distort any transmission path between the MiTM and the authenticator (30).

[0048] Additionally, the concept of traceroute can also be used here to check the number of hops required to route an IP packet (e.g., Ethernet hop count to check at regular intervals if additional hops have been introduced).

[0049] FIG. 5 is a diagram of an example environment 500 in which the systems and / or methods described herein may be implemented. As shown in FIG. 5, the environment 500 may include a supplicant (10), a MiTM (60), an authenticator (30), an authentication server (40), and a network (50). The devices of the environment 500 may be interconnected by wired connections, wireless connections, or a combination of wired and wireless connections. In some embodiments, any of the functions and operations described with reference to FIG. 6 below may be performed by any combination of the elements shown in FIGS. 4-5.

[0050] The supplicant 10 may correspond to any terminal or device of a system end user requesting access to the network 50. The supplicant 10 may submit an authentication request via an Ethernet frame, for example, as shown in FIG. 4. In this manner, the supplicant may provide authentication information (e.g., authentication information used for authentication) in the authentication request via the Ethernet frame (e.g., a data field of the Ethernet frame) or a subsequent frame. For example, the authentication information may include a username and password. Additionally, the authenticator 30 may correspond to and function as a control access point between the supplicant 10 and the authentication server 40.

[0051] The MiTM (60) device may accommodate any unauthorized entity attempting to collect, transfer or transmit any information between the supplicant (10) and the authenticator (30).

[0052] The authentication server 40 may correspond to a back-end server that performs port authentication. The authentication server 40 may include a database of information corresponding to each authentication information used by each supplicant 10 to connect to the network 50. The authenticator 30 may send the supplicant's 10 authentication information to the authenticator server 40 for authentication. If the supplicant's 10 authentication information matches the stored information, the port authentication is considered successful and the port is released. However, if the supplicant's 10 authentication information does not match, the port authentication fails and the port is disabled.

[0053] The network 50 may include one or more wired and / or wireless networks. For example, the network 50 may include a cellular network (e.g., a fifth-generation (5G) network, a long-term evolution (LTE) network, a third-generation (3G) network, a code division multiple access (CDMA) network, etc.), a cloud network, a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc., and / or a combination of these or other types of networks.

[0054] FIG. 5 illustrates an Ethernet frame flow 500 using hop counting to prevent MiTM attacks, according to embodiments disclosed herein.

[0055] The flow of Ethernet frames (501) for a regular flow is indicated by a bold line, and the presence of an MiTM entity (502-503) is indicated by a dotted line. The authenticator (30) determines whether an MiTM exists between the supplicant (10) and the authenticator (30) based on the hop count. For example, the hop count between the supplicant (10) and the authenticator (30) must be zero or less than a predetermined threshold, indicating a valid authentication request. In this case, if the hop count is not zero or greater than the predetermined threshold (503), the authenticator (30) detects that an MiTM exists between the supplicant (10) and the authenticator (30) and implements various countermeasures. For example, the authenticator (30) can disable a port as a preventative measure to prevent MiTM attacks. In some embodiments, the predetermined threshold may be greater than zero. According to some embodiments, if the hop count between the supplicant (10) and the authenticator (30) is less than a predetermined threshold, the authentication request is valid, and if the hop count is greater than or equal to the predetermined threshold, the authenticator (30) detects the presence of a MiTM.

[0056] 6 is a flowchart of an exemplary process for responding to a potential MiTM attack. The process shown in FIG. 6 may begin at S610, where the authenticator (30) receives an authentication request from the supplicant (10) via an Ethernet frame through a port of the authenticator (30). The process may proceed to step S620, where the authenticator (30) then obtains a hop count from the Ethernet frame, corresponding to the number of hops in the transmission path between the supplicant (10) and the authenticator (30). If the Ethernet frame is hopped (e.g., received and forwarded) through any device or entity in the transmission path between the supplicant (10) and the authenticator (30), the hop count in the Ethernet frame is incremented.

[0057] Processing continues at step S630, where the authenticator 30 compares the hop count with a predetermined threshold to determine whether the hop count is greater than the predetermined threshold. The predetermined threshold represents an acceptable number of hops. The threshold may be configured by a network administrator, a security administrator, or the like, based on the topology of the network 50. If the hop count is greater than the predetermined threshold (Yes), the authentication request is determined to be invalid, as shown at S640, and the port is disabled due to authentication failure. If the hop count is not deemed greater than the predetermined threshold (No), and port authentication is successful, the port is opened, as shown at step S650.

[0058] In other embodiments, the effect of introducing a hop count is that the impact of the change in the Ethernet frame(s) is taken into account by all L2 entities. Traceroute can also be incorporated to introduce additional frames at regular intervals to check for changes in the hop count.

[0059] In other embodiments, additional configuration of a predetermined threshold may be restricted to be within an L2 link similar to configuration of maximum transmission unit (MTU), medium access control (MAC) address, etc. For the hop count, a default of 0 / 255 may be used.

[0060] In other embodiments, the MiTM (60) may observe the Ethernet frame(s) from the supplicant (10) and change or reset the hop count value.

[0061] The embodiments disclosed herein may be implemented using at least one hardware device to perform network management functions for controlling the elements.

[0062] The foregoing description of specific embodiments sufficiently reveals the general nature of the embodiments herein, so that others, by applying current knowledge, can easily modify and / or adapt such specific embodiments to various uses without departing from the broader concept; therefore, such adaptations and modifications should, and are intended to, be understood within the meaning and range of equivalents of the disclosed embodiments. It should be understood that the phraseology or terminology used herein is for purposes of description and not limitation. Thus, although the embodiments herein have been described with reference to preferred embodiments, those skilled in the art will recognize that the embodiments herein can be modified and practiced within the scope of the embodiments described herein.

Claims

1. 1. A method, implemented by at least one processor, for protecting a fronthaul link from man-in-the-middle (MiTM) attacks in a network communication system, comprising: receiving an authentication request for port authentication from a supplicant via an Ethernet frame through a port of the authenticator; acquiring, by the authenticator, from the Ethernet frame, a hop count corresponding to the number of hops in a transmission path of the Ethernet frame between the supplicant and the authenticator; comparing the hop count to a predetermined threshold to determine whether the port should be disabled; and disabling the port based on the hop count being greater than the predetermined threshold.

2. The method of claim 1 , wherein the predetermined threshold is set on the port of the authenticator, and the port is an L2 interface.

3. The method of claim 1 , wherein the hop count is obtained from a header of the Ethernet frame.

4. 4. The method of claim 3, wherein the header of the Ethernet frame includes a 6-byte preamble and a 1-byte hop count field in which the hop count is recorded.

5. 5. The method of claim 4, wherein the hop count field is between the preamble and a start frame identifier (SFD) field.

6. The method of claim 1 , wherein the hop count is incremented within the Ethernet frame by any device included in the transmission path.

7. The method of claim 1 , wherein the port authentication is IEEE 802.1x port authentication.

8. 1. An apparatus for protecting a fronthaul link from man-in-the-middle (MiTM) attacks in a network communication system, comprising: a memory for storing instructions; at least one processor, receiving a port authentication request from a supplicant via an Ethernet frame through the authenticator's port; obtaining, from the Ethernet frame, a hop count corresponding to the number of hops in a transmission path of the Ethernet frame between the supplicant and the authenticator, by the authenticator; comparing the hop count to a predetermined threshold to determine whether the port should be disabled; at least one processor configured to execute the instructions to disable the port based on the hop count being greater than the predetermined threshold; An apparatus comprising:

9. The apparatus of claim 8 , wherein the predetermined threshold is set on the port of the authenticator, and the port is an L2 interface.

10. The apparatus of claim 8 , wherein the hop count is obtained from a header of the Ethernet frame.

11. 11. The apparatus of claim 10, wherein the header of the Ethernet frame includes a 6-byte preamble and a 1-byte hop count field in which the hop count is recorded.

12. 12. The apparatus of claim 11, wherein the hop count field is between the preamble and a start frame identifier (SFD) field.

13. The apparatus of claim 8 , wherein the hop count is incremented within the Ethernet frame by any device included in the transmission path.

14. The apparatus of claim 8 , wherein the port authentication is IEEE 802.1x port authentication.

15. 1. A method for protecting a fronthaul link from a man-in-the-middle (MiTM) attack in a network communication system, comprising: receiving an authentication request for port authentication from a supplicant via an Ethernet frame through a port of the authenticator; acquiring, by the authenticator, from the Ethernet frame, a hop count corresponding to the number of hops in a transmission path of the Ethernet frame between the supplicant and the authenticator; comparing the hop count to a predetermined threshold to determine whether the port should be disabled; Disabling the port based on the hop count being greater than the predetermined threshold; A non-transitory computer-readable storage medium having stored thereon instructions executable by at least one processor to implement a method including:

16. 16. The non-transitory computer-readable medium of claim 15, wherein the predetermined threshold is set on the port of the authenticator, and the port is an L2 interface.

17. 16. The non-transitory computer-readable medium of claim 15, wherein the hop count is obtained from a header of the Ethernet frame.

18. the header of the Ethernet frame includes a 6-byte preamble and a 1-byte hop count field in which the hop count is recorded; 20. The non-transitory computer-readable medium of claim 17, wherein the hop count field is between the preamble and a start frame identifier (SFD) field.

19. 16. The non-transitory computer-readable storage medium of claim 15, wherein the hop count is incremented within the Ethernet frame by any device included in the transmission path.

20. 16. The non-transitory computer-readable storage medium of claim 15, wherein the port authentication is IEEE 802.1x port authentication.

Images