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 exemplary 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 can attack 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, unauthorized 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 (3), 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) may be a unauthorized switch, unauthorized bridge, etc., as shown in FIG. 1. Specifically, the unauthorized entity (20) connects to a port of the authenticator (30) to transmit data. However, the port needs to be opened before any data can be transmitted. That is, the port authentication must be considered successful in order to open the port and start 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 function) and initiates 802.1x authentication with the unauthorized entity (20). For example, the supplicant (10) sends an authentication request to the unauthorized switch instead of sending a request to the authenticator (30). The unauthorized entity (20) then forwards packets (e.g., authentication requests) to the actual authenticator (30) during authentication. If the authentication is successful, the port is opened at the authenticator (30). As a result, the MiTM (60) can 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 using the unauthorized entity (20). Thus, the MiTM attack is launched 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, for example, a MiTM (60), as shown in FIG. 2. The attacker's terminal device acts as a rogue entity itself and connects to a port of the authenticator (30) without a rogue switch / bridge. The terminal device forwards packets to and from the authenticator (30). If the 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 into 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 protect 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 man-in-the-middle (MiTM) attacks 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, a hop count from the Ethernet frame corresponding to a 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.

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

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

[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 in an 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 execute instructions to receive an authentication request for port authentication from a supplicant via an Ethernet frame through a port of an authenticator, obtain from the Ethernet frame, by the authenticator, 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 disable the port based on the hop count being greater than the predetermined threshold.

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

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

[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 in an 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 man-in-the-middle (MiTM) attacks 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, a hop count from the Ethernet frame corresponding to a 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.

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

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

[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 between the preamble and the starting frame identifier (SFD) field.

[0026] The hop count is incremented in an 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 / without the use of an unauthorized entity (e.g., a unauthorized 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 illustrated embodiments of the present disclosure. [Brief description 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] Related technology shows a MiTM attack using a malicious switch / bridge. [Diagram 2] We present a related technique for a MiTM attack that does not use a malicious switch / bridge. [Diagram 3] 1 illustrates 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. [Diagram 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 man-in-the-middle (MiTM) attacks, in accordance with an example embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[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 illustrations and descriptions, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Furthermore, one or more features or components of one embodiment may be incorporated in or combined with another embodiment (or one or more features of another embodiment). In addition, in the flowcharts and descriptions of operations provided below, it is 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) simultaneously, 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 dedicated control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, 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 is inclusive of all other claims in the set of claims.

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

[0039] The embodiments herein and various features and advantageous details thereof 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 so as not to unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, since some embodiments can be combined with one or more other embodiments to form new embodiments. The term "or" used herein refers to a non-exclusive or, unless otherwise specified. The examples used herein are only intended 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. Thus, the examples should not be interpreted as limiting the scope of the embodiments herein.

[0040] As is conventional in the art, the embodiments may be described and illustrated in terms of blocks performing one or more described functions. These blocks, sometimes referred to herein as units or modules, 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 constituting the blocks may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuits), or by a combination of dedicated hardware for performing some functions of the blocks and a processor for performing other functions of the blocks. Each block of the embodiments may be physically separated into two or more interacting individual blocks without departing from the scope of the invention. Similarly, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the 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. Thus, the present disclosure should be construed to extend to 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 / 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 instead of the traditional 7 bytes as 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). That is, 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 preventative measure to prevent MiTM attacks.

[0045] For example, during an authentication process, the supplicant (10) sends an authentication request to the authenticator (30) via an 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 sent over the network (50) using a rogue entity (20) or man-in-the-middle device (60). The rogue entity may include a rogue switch, a rogue bridge, etc. The Ethernet frame(s) is 64 bytes, and the hop count will be 1 byte long with a value between 0 and 255. The hop count is derived from a 7-byte preamble consuming 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 is 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 with 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 predefined threshold configured by a network administrator, security administrator, etc. based on the topology of the network (50).

[0047] In some embodiments, the authenticator (30) can disable a port if the hop count value in the frame is greater than a set minimum predefined threshold. A greater hop count value indicates that a MiTM entity may be present or some external rogue entity has been involved in sending data and ultimately incrementing the hop count. Thus, the authenticator (30) disables the port as a precautionary measure 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 counting 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 implemented by any combination of 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 an information database corresponding to each authentication information used by each supplicant 10 to connect to the network (50). The authenticator (30) may send the authentication information of the supplicant (10) to the authenticator server (40) for authentication. If the authentication information of the supplicant (10) matches the stored information, the port authentication is considered successful and the port is released. However, if the authentication information of the supplicant (10) 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 frame(s) in the case of regular flow (501) is shown in bold and in the case of the presence of a MiTM entity (502-503) is shown in dotted lines. The authenticator (30) determines whether a 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 predefined threshold, which indicates a valid authentication request. In that case, if the hop count is not zero or is greater than a predefined threshold (503), the authenticator (30) detects that a 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 predefined threshold may be a number 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 flow chart 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, which corresponds 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 to a predefined threshold to determine whether the hop count is greater than the predefined threshold. The predefined threshold represents an acceptable number of hops. The threshold may be configured by a network administrator, a security administrator, etc., based on the topology of the network (50). If the hop count is greater than the predefined 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 to be greater than the predefined threshold (No), and the 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. A 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 configurations of a predefined threshold may be restricted to be within an L2 link similar to configurations 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 modify 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 above description of the specific embodiments fully reveals the general nature of the embodiments of the present specification, so that others can easily modify and / or adapt such specific embodiments to various applications by applying current knowledge without departing from the general concept, and 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 expressions or terms used in the present specification are for the purpose of description and not for the purpose of limitation. Thus, although the embodiments of the present specification have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments of the present specification can be modified and implemented within the scope of the embodiments described herein.

Claims

1. 1. A method for protecting a fronthaul link from man-in-the-middle (MiTM) attacks in a network communication system, the method 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 a 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 configured in the port of the authenticator, the port being 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 a man-in-the-middle (MiTM) attack in a network communication system, comprising: A memory for storing instructions; At least one processor, receiving an authentication request for port authentication from a supplicant via an Ethernet frame through the authenticator's port; obtaining, 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; 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 configured in the port of the authenticator, the port being 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 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 a 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 recording 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 configured in the port of the authenticator, the port being 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 medium of claim 15, wherein the port authentication is IEEE 802.1x port authentication.

Images