Time Synchronization Security using IPsec and MACsec Tal Mizrahi Marvell Yokneam, Israel
[email protected]
Abstract—The wide deployment of the IEEE 1588 Precision Time Protocol (PTP) raises significant security concerns; its quick assimilation has outrun security standardization efforts. In the absence of a standard security solution for PTP, several different alternatives have been suggested as a means to fill this vacuum using existing off-the-shelf security protocols. In this paper, we analyze PTP security solutions using two such protocols; IPsec and MACsec. We characterize the common deployment scenarios for PTP using these protocols, and then present a security threat analysis under these scenarios. Keywords: IEEE 1588, PTP, security, IPsec, MACsec, time synchronization.
I.
INTRODUCTION
Time synchronization protocols have been around for many years. The Network Time Protocol (NTP) provides end-to-end time synchronization between end stations in IP networks. The growing need for high accuracy gave birth to the IEEE 1588 [6]. This protocol achieves high precision by hop-by-hop synchronization, where intermediate nodes can participate in the synchronization mechanism, thus eliminating inaccuracies caused by multiple network hops. NTP was conceived with security in mind. It includes an inherent security protocol that provides a symmetric key authentication scheme. The Autokey protocol [8] is the latest extension to the NTP security architecture, using a public key authentication scheme rather than the symmetric key scheme. While NTP uses an end-to-end security scheme, where traffic is protected between the master and the slave, the IEEE 1588, introduces a security challenge due to its per-hop synchronization approach. An end-to-end security approach is generally more robust and secure, whereas the need for the participation of multiple intermediate nodes in the protocol is a real challenge from the security perspective. The IEEE 1588 was not designed with an inherent security mechanism. Annex K of the IEEE 1588-2008 [6] standard defines an experimental security protocol for PTP, but was never formalized into a properly-defined security protocol. Currently, the IEEE 1588 does not have a standard security mechanism. As the IEEE 1588 is becoming commonly used and deployed, the market demand for a security mechanism has
preceded its standardization. As a result, ad-hoc solutions have been proposed to secure PTP using existing security protocols, while the security standardization process still lingers. Security aspects of the IEEE 1588 protocol have been analyzed in several papers ([7], [12]), including an analysis of security vulnerabilities. Numerous papers have been published with respect to security vulnerabilities of the IPsec protocol, e.g., [5]. The usage of IPsec [11] for securing time synchronization was analyzed in [1] and [3]. They focus on the implications of IPsec on protocol precision and performance, and on hardware implementation aspects. The authors of [9] present the need to use IPsec in PTP enabled networks, and suggest a method to identify PTP packets when they are encrypted by IPsec. In [2], it was suggested to use MACsec ([12], [14]) to secure the IEEE 1588 protocol. However, up to this point, no analysis has been done on the security aspects of using IPsec and MACsec to secure time synchronization. This paper focuses on two methods of securing IEEE 1588 using existing security protocols: IPsec and MACsec. We characterize the typical deployment scenarios, and perform a threat analysis of these scenarios. The remainder of this paper is organized as follows. Section II provides a short overview of IPsec and MACsec, and describes two typical deployment scenarios of time synchronization security with these two protocols. Section III is the main part of this work. It provides a detailed analysis of security threats to the IPsec and MACsec deployment scenarios. Concluding remarks are provided in Section IV. II.
SECURING PTP WITH IPSEC AND MACSEC
A. IPsec and MACsec Overview 1) IPsec IPsec is a suite of security protocols for IP networks that was defined in the IETF. IPsec provides two main functions, allowing two modes of operation: •
Authentication-only mode, using an Authentication Header (AH) that is added to each IP packet. The AH includes a cryptographic Integrity Check Value (ICV), protecting the integrity of the packet, and a 4-byte sequence number providing replay protection.
•
Encapsulating Security Payload (ESP) mode. The ESP protects the confidentiality of the data using payload encryption, in addition to the integrity and replay protection mechanisms that are similar to the ones in the AH.
Both the AH and ESP can operate in tunnel mode or in transport mode. In transport mode, only the IP payload is encrypted or authenticated.In tunnel mode, the IP header and payload are encrypted or authenticated as a bundle, and a new IP header is added to the encapsulating packet. 2) MACsec MACsec is a protocol for L2 link-level security. The IEEE 802.1AE [13] defines the encryption and authentication protocol, whereas the IEEE 802.1X [14] defines the session initiation and key management. The security architecture in MACsec follows a hop-by-hop encryption approach, where packets are decrypted at each bridge in the network, and then encrypted again before being relayed to its destination. Confidentiality is provided by encrypting the entire packet excluding the source and destination MAC addresses. The MACsec header, also known as the SecTAG, resides immediately after the MAC addresses. MACsec also supports a mode of operation that performs authentication without encryption. Integrity and replay protection are assured in a similar manner to the IPsec approach; a 16-byte ICV protects the integrity of the entire packet, including the L2 header and the SecTAG. A 4-byte Packet Number (PN) is used for replay protection. B. Time Synchronization Security A time synchronization protocol allows multiple nodes to align their time value to a common reference clock. The three main aspects of information security are Confidentiality, Integrity, and Availability. •
Confidentiality: This is a minor issue for most time synchronization applications. In some cases, where service providers charge payment for timing information, confidentiality may play a more important role, but these cases are esoteric.
•
Availability: It is always desirable to design a protocol that is robust to denial of service attacks. Every network is prone to DoS attacks and thus, it is reasonable to require a timing protocol to be as resistant to DoS attacks as the network it is transported over.
•
Integrity: Each node must verify the correctness of the timing information it receives. It verifies that the received information is intact, without being tampered with, and that it arrives from an authentic source. When the data integrity is compromised by an attacker, the impact is that attacked nodes align to a false time value.
Thus, for time synchronization protocols, integrity and authentication are the most important security goals. The
security mechanisms discussed in this paper target these two goals. C. Securing Time SynchronizationTypical Scenarios The integrity protection required in time synchronization can be provided by both IPsec and MACsec. Both IPsec and MACsec use an authentication process to verify the authenticity of peer nodes, and use an Integrity Check Value (ICV) to protect the integrity of the data. Both protocols can optionally support data encryption, providing confidentiality of the underlying data. Confidentiality is less relevant for timing protocols. Therefore, in our analysis, we do not place a restriction on whether data encryption should or should not be used. We generically use the term “to secure” the traffic, to refer to data authentication with or without encryption. A security mechanism can be deployed in one of two approaches; an end-to-end security approach, or a hop-by-hop approach. In the end-to-end approach, the data is signed or encrypted by the originator of the data, and then verified or decrypted at the destination. Intermediate nodes cannot verify or decrypt the data, since they do not posses the cryptographic keys. In the hop-by-hop approach, on the other hand, the data is verified or decrypted at each hop, and then re-signed, or reencrypted by the current node. Clearly the end-to-end approach is a more conservative approach, since only the source and the destination of the data posses the keys, and the data is less exposed to malicious attacks. The hop-by-hop security approach is needed when intermediate nodes must be able to read or modify the data before relaying it. In Figure 1 and Figure 2, we illustrate two typical deployment scenarios of time synchronization security mechanisms.
Figure 1. The IPsec Scenario IPsec Tunneling over an Untrusted Network
Figure 1 presents a typical example of securing time synchronization traffic using IPsec. The customer and operator networks are connected through an untrusted public network, and thus data sent through the public network is secured between two Security Gateways (GW) using IPsec in a network-to-network configuration. Specifically, timing protocol messages are also secured through the IPsec tunnel. An example of such a system (see [10]) is a cellular femtocell, where the slave clock resides in the home network, and the master resides in the operator’s core network. An IPsec tunnel
secures all traffic between the two networks, because this traffic is transported over a public provider network. In Figure 2 we present a typical system using MACsec for time synchronization security. The master and slave both reside in the same L2 local area network (LAN), and MACsec is used to secure the traffic at each hop in the L2 network.
Security vulnerabilities are often a result of incorrect configuration of the protocol parameters, or as a result of disabling some of its security features. In our analysis we assume that the protocols are configured correctly. Specifically, we assume that each pair of security nodes maintains a unique pair-wise cryptographic key, preventing some of the most trivial attacks that result from using a commonly shared key. A. Threat Classification In our threat analysis, we distinguish several types of attackers. Internal vs. external: An internal attacker has access to a trusted segment of the network, or possesses the encryption or authentication keys. An external attacker, on the other hand, does not have the keys, and is exposed only to the encrypted or authenticated traffic. Thus, an internal attacker can maliciously tamper with legitimate traffic in the network, as well as generate its own traffic and make it appear legitimate to its attacked nodes.
Figure 2. The MACsec Scenario Hop-by-Hop MACsec Encryption in an L2 Network
Note that in both of the above scenarios, IPsec and MACsec can be used to secure all the data transmitted through the untrusted links, or they can be used to selectively secure only the time synchronization protocol traffic.
Man-in-the-Middle (MITM) vs. Injector: A MITM attacker is located in a position that allows interception and modification of in-flight protocol packets, while a traffic injector cannot intercept legitimate packets, but can record them, replay old messages, and generate its own traffic.
We use the term security node as a generic term that refers to a node that takes part in a security protocol, either IPsec or MACsec. In the IPsec Scenario the security gateways play this role, while in the MACsec Scenario the security nodes are each bridge and clock in the network. Throughout this paper, we refer to the two scenarios presented in Figure 1 and Figure 2 as the IPsec Scenario and the MACsec Scenario. Note, however, that despite the terminology, the MACsec Scenario could in fact be deployed using IPsec as the security protocol, and similarly, the IPsec Scenario could be adjusted slightly to use MACsec. The analysis in this paper does not compare the IPsec protocol versus the MACsec protocol, but rather compares the two scenarios in Figure 1 and Figure 2 III.
In this section, we analyze the security threats in the context of the IPsec and MACsec scenarios. We use the IEEE 1588 security annex as a reference point. Note that although this security annex was defined in the standard as experimental, it is still interesting to use it as a reference point in our threat analysis1. We first characterize the types of attackers in our context, and then provide a list of possible attacks. For each attack, the Applicability subsection specifies which of the three security mechanisms is exposed. A summary of the analysis is presented in TABLE I.
1
Figure 3. Attacker Types
THREAT ANALYSIS
NTP could also be an interesting reference point, as it is exposed to similar vulnerabilities, however in this analysis we chose the security annex of the IEEE 1588 as a reference.
Following the two distinctions above, we define four types of attackers in our threat analysis (see Figure 3): •
Mary—Internal Man-in-the-Middle Mary can be located within the premises of a trusted network (Mary 1 in the figure), or have access to an intermediate node with the cryptographic keys (Mary 2 in the figure).
•
Jeanie—Internal Injector Jeanie can inject traffic from within a trusted network (Jeanie 1 in the figure), or have access to a node with the cryptographic keys that is not located as a MITM (Jeanie 2 in the figure).
•
Emma—External Man-in-the-Middle
•
Enya—External Injector
For each of the threats that we refer to in the next subsection, we specify the attacker types that can perform it. B. Threats 1) Packet interception and manipulation Synopsis: The attacker modifies legitimate protocol messages. Description: Mary can intercept protocol packets, and tamper with the timestamp information, e.g., the originTimestamp and correctionField 2 . A systematic modification of these fields causes the receiving nodes to align to a false time value. Other fields in the protocol messages can be altered, causing a DoS attack, e.g., the messageType, versionPTP, and twoStepFlag. Applicability: MACsec Scenario, IPsec Scenario, and Annex K. This attack can be performed regardless of the security mechanism used, since it is performed by an internal attacker who is completely unaffected by the security mechanism.
3) Replay attack Synopsis: The attacker captures protocol messages and replays them. Description: Mary or Jeanie can snoop and archive a series of protocol messages, and then transmit the set of message at a later time. Applicability: MACsec Scenario, IPsec Scenario, and Annex K. An internal attacker can perform this attack regardless of the security mechanism used. All three of the analyzed security mechanisms have an inherent replay protection mechanism, preventing external attackers from replaying messages. Impact: Receiving nodes are aligned to a false time value. 4) Rogue master attack Synopsis: The attacker can manipulate the best master clock selection and become a master.
2) Spoofing Synopsis: The attacker spoofs a legitimate clock in the network, and generates fabricated protocol messages.
Description: The best master clock selection is based on the properties advertised by each clock in its Announce messages. The master selection is based on the clock quality advertised in the Announce message. When multiple clocks have the same quality, the clock’s MAC address is used as a tie breaker. Mary or Jeanie can easily become masters by generating malicious Announce messages and manipulating the clock quality and MAC address3.
Description: The internal attackers, Mary and Jeanie, can generate spoofed protocol messages that appear to the receiver to arrive from a legitimate clock in the network.
Applicability: MACsec Scenario, IPsec Scenario, and Annex K. An internal attacker can perform this attack regardless of the security mechanism used.
Applicability: MACsec Scenario, IPsec Scenario, and Annex K. This attack can be performed by an internal MITM attacker regardless of the security mechanism used. Specifically, in the IPsec Scenario as illustrated in Figure 1, an Internal Injector (Jeanie 1) located in the customer network or in the operator network can perform this attack, masquerading as the slave or master clock respectively. This case is specific to the IPsec Scenario, since it uses a network-to-network configuration, in which an intruder can perform an attack from inside the network, even if it is not located at a MITM position.
Impact: Nodes are connected to a rogue master, and are thus aligned to a false time value.
Impact: Receiving nodes are aligned to a false time value, or denial of service.
Let us consider another spoofing example, where Jeanie 2 transmits malicious messages to Slave 1, in an attempt to spoof the Master Clock. This attack is effective in the IPsec Scenario, since malicious messages from Jeanie 2 to Slave 1 are successfully received by the security gateway and forwarded to Slave 1. The attack is not applicable to the MACsec Scenario or to Annex K, where Jeanie 2 can spoof messages from Slave 2, but cannot spoof messages from the Master Clock. The reason is that we are assuming that each pair of security nodes have a unique pair-wise key. Thus, when Slave 1 receives a spoofed message from Jeanie 2, the cryptographic key used for verifying the message proves that the message arrived from Jeanie 2 and not from the Master Clock. Impact: Receiving nodes are aligned to a false time value.
2
PTP messages use the originTimestamp and correctionField to convey timing information. The originTimestamp specifies the time of transmission from the source of the message, and the correctionField specifies the accumulated latency added by intermediate clocks in the network.
5) Packet Interception and Removal Synopsis: The attacker intercepts packets and prevents them from arriving to their destination. Description: The attack can be performed by a man-in-themiddle. Mary or Emma can either disrupt all protocol messages from arriving to their destination, or systematically remove specific message to reduce the accuracy of the protocol. Applicability: MACsec Scenario, IPsec Scenario, and Annex K. A MITM attacker, both internal and external, can perform this attack, since it requires the attacker to be located at an intermediate location, regardless of whether it has access to the encryption keys. Impact: Denial of service or accuracy degradation. 6) Packet delay manipulation Synopsis: The attacker intercepts protocol messages, and maliciously delays them before relaying them to the destination. Description: Mary or Emma can intercept and record protocol messages, and then transmit them at a later time, causing the receiving nodes to falsely measure the network delay. The most naïve attack is to delay the transmission of each protocol message by a constant delay D, causing an error of D in the time value of the receiving nodes. A more elaborate attack requires the adversary to aggregate a large number of protocol packets, and then to transmit them periodically at a 3
This attack is described in [12] in greater detail.
TABLE I.
Attacker Type
Description: An attacker can use any one of numerous possible L2/L3 well-known denial of service attacks, e.g., address flooding, Smurf attack, ping of death, and many others. Applicability: L2/L3 DoS attacks can be performed by both internal and external attackers. The IEEE 1588 Annex K mechanism is exposed to both L2 and L3 attacks, since the protocol only secures the PTP layer, and does not secure lower layers. IPsec performs security at L3, i.e., it protects the IP payload and some of the fields in the IP header, and is thus exposed to attacks at L2, and to some attacks at L3. MACsec protects the L2 payload and header, and is thus not exposed to these attacks. Impact: Denial of service. 8) Cryptographic Performance Attack Synopsis: An attacker utilizes the cryptographic elements in the device under attack, creating a performance bottle neck. Description: An attacker can take advantage of the high performance cost of the cryptographic security protocols. For example, the Security Gateway in the IPsec Scenario can in some deployments be a bottleneck in the network, i.e., it may have a lower cryptographic processing bandwidth than its interface to the provider network. In this case, an attacker may use a relatively low traffic bandwidth to attack the security gateway. An example of such an attack is sending a bogus encrypted message with a false ICV. The security gateway receives the message, attempts to decrypt it and checks the ICV. Only after checking the ICV does the security gateway drop the bogus packet. Applicability: MACsec Scenario, IPsec Scenario, and Annex K. This attack can be performed by all types of attackers, including external attackers. Impact: Denial of service. 9) Time source spoofing Synopsis: An attacker spoofs the accurate time source of the master. Description: master clocks use an accurate time source, which is typically based on an atomic clock, or a GPS based clock. The information received from the GPS system is unsecured, allowing an attacker to transmit false GPS data, and cause the master to distribute a false time of day value. Applicability: MACsec Scenario, IPsec Scenario, and Annex K. This attack is independent of the protocol message security, since it attacks the time source.
Interception and modification
•
•
•
Spoofing
•
•
•
Replay
•
•
•
•
•
•
Rogue master
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Interception and removal Delay manipulation L2/L3 DoS Cryptographic performance Time source spoofing
IV.
IPsec 1588 Annex K
External Injector MACsec
External MITM IPsec 1588 Annex K
Attack
Internal Injector
IPsec 1588 Annex K MACsec
Internal MITM
Impact: Receiving nodes are aligned to a false time value. 7) Well known L2/L3 DoS attacks Synopsis: An attacker can attack L2/L3 protocols. These types of attacks are not specifically targeted at the time synchronization protocol, but at other layers in the protocol stack.
THREAT ANALYSIS - SUMMARY
IPsec 1588 Annex K MACsec
Applicability: MACsec Scenario, IPsec Scenario, and Annex K. Similar to the packet interception attack, this attack can be performed by a MITM attacker, both internal and external.
Impact: all slaves align to a false time value.
MACsec
slightly different period than they were originally sent by the originator. The latter attack causes the receiving node to align to a false time value, as well as a false frequency.
•
•
•
•
•
•
•
•
•
CONCLUSION
In this paper we analyzed two deployment scenarios of IEEE 1588 security using IPsec and MACsec. The IPsec scenario (Figure 1), and the MACsec scenario (Figure 2), are two different use cases of secure time synchronization. We performed a comparison of the two different network scenarios. The analysis in this paper does not attempt to compare IPsec and MACsec. Rather than analyzing these two protocols, we analyze two common use cases of these protocols for securing PTP, and compare the two use cases. TABLE II summarizes the highlights of this comparison. The IEEE 1588 Annex K experimental security protocol is presented as a reference. The results in TABLE II present an apples-tooranges comparison; the MACsec scenario and the IPsec scenario solve two different problems, and thus should not be considered as two competing solutions, but rather as complementary solutions. As presented in TABLE II, MACsec secures time synchronization in native L2 Ethernet networks. Clearly, since MACsec operates at L2, it is not vulnerable to common L2/L3 DoS attacks. IPsec, on the other hand, is used in L3 IP networks, and is thus exposed to some of these attacks. IPsec is specifically useful when tunneling time synchronization (or other) traffic over a public untrusted IP network. PTP is by nature a hop-by-hop time synchronization protocol, where Transparent Clocks (TCs) and Boundary Clocks (BCs) can be used as intermediate points between master and slaves, allowing high clock precision. However, the large number of nodes involved in the protocol imposes a real security challenge, since every cryptographic mechanism is as weak as the number of nodes that hold the cryptographic keys. In the IPsec scenario, intermediate nodes between the two tunnel end points do not take part in the time synchronization protocol. Thus, the IPsec scenario does not provide the accuracy of the MACsec scenario, but is also less vulnerable to
attacks from intermediate nodes. Therefore, it is more robust to MITM attacks.
Threats
Requirements
TABLE II.
TIME SYNCHRONIZATION SECURITY SOLUTIONSSUMMARY MACsec Scenario
IPsec Scenario
Network
L2 typically LAN
Security approach
Hop-by-hop
Accuracy
+ (TCs/BCs)
L3 typically public network Network-tonetwork ~ (no TCs/BCs)
+
-
L2/L3 Attack Prevention Robustness to Internal injector attacks (Jeanie 1 in Figure 3) Robustness to internal MITM attacks (Mary 2 in Figure 3)
IEEE 1588 Annex K
Any
solutions for different network topologies and environments. In some cases, a hybrid solution that combines the two protocols should be considered, providing the benefits of both mechanisms. In this sense, IPsec and MACsec are not competing solutions, but rather two complementary solutions with regards to time synchronization. Indeed, in the next few years, we expect to see increasing usage of these intermediate solutions to bridge the gap between the publication of the 1588 and the standardization of its security protocol.
Hop-by-hop + (TCs/BCs)
REFERENCES [1]
[2]
+
-
+ [3]
[4] -
+
[5]
[6]
On the other hand, in the IPsec scenario, time synchronization protocol messages are secured between two security gateways, residing at the provider edge. This approach assumes that the operator’s local area network is a secure perimeter. This assumption is not always valid, i.e., we do not always want an individual with access to the operator network to be able to attack the time synchronization protocol. The operator’s LAN may be exposed to internal attacks. Thus, the MACsec scenario is more robust to Internal Injector attacks. To mitigate this vulnerability, a hybrid solution can be used, combining IPsec and MACsec, as shown in Figure 4. A hybrid solution should be carefully analyzed and tailored on a per-case basis, based on the network structure and topology, in a way that provides the benefits of both protocols without presenting new threats. For example, the hybrid security gateway should be designed in a way that does not increase the vulnerability to cryptographic performance attacks, even though it operates both IPsec and MACsec.
Figure 4. Hybrid scenarioIPsec and MACsec
In conclusion, in the absence of a standard security mechanism for IEEE 1588, both IPsec and MACsec can be considered as valid intermediate time synchronization security
[7]
[8] [9] [10] [11] [12]
[13] [14]
A. Treytl, B. Hirschler, “Securing IEEE 1588 by IPsec tunnels - An analysis”, in Proceedings of 2010 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2010, pp. 83-90, 2010. T. Koskiahde, J. Kujala and T. Norolampi, "A Sensor Network Architecture for Military and Crisis Management" in Proceedings of International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2008, Ann Arbor, Michigan, USA, pp. 110-114, 2008. A. Treytl, B. Hirschler, and T. Sauter, “Secure tunneling of high precision clock synchronisation protocols and other timestamped data,” vol. ISBN 978-1-4244-5461-7, pp. 303–313, Nancy, France, May 2010. V. Nikov, “A DoS Attack Against the Integrity-Less ESP (IPSec)”, International Conference on Security and Cryptograph, 2006. J.P. Degabriele, K.G. Paterson, “Attacking the IPsec Standards in Encryption-only Configurations” IEEE Symposium on Security and Privacy 2007, pp. 335 – 349, 2007. IEEE TC 9 Test and Measurement Society 2000, “1588 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2”, IEEE Standard, 2008. A. Treytl and B. Hirschler, “Security Flaws and Workarounds for IEEE 1588 (Transparent) Clocks,” in Proceedings of 2007 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2007, pp. 1-6, 2009. B. Haberman, D. Mills, U. Delaware, “Network Time Protocol Version 4: Autokey Specification”, IETF, RFC 5906, 2010. Y. Xu, “IPsec security for packet based synchronization”, IETF, draftxu-tictoc-ipsec-security-for-synchronization (work in progress), 2010. 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TS 33.320 10.2.0 (work in progress), March 2011. S. Kent, K. Seo, “Security Architecture for the Internet Protocol”, IETF, RFC 4301, 2005. A. Treytl, G. Gaderer, B. Hirschler and R. Cohen, “Traps and pitfalls in secure clock synchronization” in Proceedings of 2007 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2007, pp. 18-24, 2007. IEEE 802.1AE-2006, “IEEE Standard for Local and Metropolitan Area Networks – Media Access Control (MAC) Security”, 2006. IEEE 802.1X-2010, “IEEE Standard for Local and Metropolitan Area Networks – Port-Based Network Access Control”, 2010.
