US20230099263A1 - Secure link aggregation - Google Patents
Secure link aggregation Download PDFInfo
- Publication number
- US20230099263A1 US20230099263A1 US18/074,203 US202218074203A US2023099263A1 US 20230099263 A1 US20230099263 A1 US 20230099263A1 US 202218074203 A US202218074203 A US 202218074203A US 2023099263 A1 US2023099263 A1 US 2023099263A1
- Authority
- US
- United States
- Prior art keywords
- network device
- peer network
- peer
- link
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000002776 aggregation Effects 0.000 title abstract description 33
- 238000004220 aggregation Methods 0.000 title abstract description 33
- 238000000034 method Methods 0.000 claims abstract description 34
- 230000008878 coupling Effects 0.000 claims abstract description 17
- 238000010168 coupling process Methods 0.000 claims abstract description 17
- 238000005859 coupling reaction Methods 0.000 claims abstract description 17
- 238000012545 processing Methods 0.000 claims description 34
- 230000004044 response Effects 0.000 claims description 16
- 230000007246 mechanism Effects 0.000 claims description 11
- 238000013459 approach Methods 0.000 description 18
- 230000015654 memory Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 10
- 230000008569 process Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 5
- 238000004590 computer program Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 239000004744 fabric Substances 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 230000004931 aggregating effect Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000001514 detection method Methods 0.000 description 2
- 230000005291 magnetic effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- PWHVEHULNLETOV-UHFFFAOYSA-N Nic-1 Natural products C12OC2C2(O)CC=CC(=O)C2(C)C(CCC2=C3)C1C2=CC=C3C(C)C1OC(O)C2(C)OC2(C)C1 PWHVEHULNLETOV-UHFFFAOYSA-N 0.000 description 1
- 241001223864 Sphyraena barracuda Species 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 229910052802 copper Inorganic materials 0.000 description 1
- 239000010949 copper Substances 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/069—Authentication using certificates or pre-shared keys
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
- H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/16—Discovering, processing access restriction or access information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/14—Direct-mode setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/15—Setup of multiple wireless link connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/02—Data link layer protocols
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
Definitions
- Embodiments of the present invention generally relate to network security and link aggregation.
- embodiments of the present invention relate to link aggregation control protocol (LACP) and verification of peer devices before allowing links to become active within a link aggregation group (LAG).
- LACP link aggregation control protocol
- LAG link aggregation group
- Link aggregation allows multiple physical links between two end-points to be aggregated together to form a LAG by combining multiple network interfaces into a single logical interface to increase throughput and provide redundancy in case of link failures.
- a Media Access Control (MAC) client can treat the LAG (which may also be referred to as a virtual link or bundle) as a single logical link.
- Link aggregation provides network redundancy by load-balancing traffic across all available links. If one of the links fails, the system automatically load-balances traffic across all remaining links.
- directly-connected network devices that also implement LACP (which may be referred to herein as link peers or simply peers) can automatically aggregate links together based on a set of specific properties negotiated, for example, via LACP.
- LACP link peers
- a network device present in a secure domain discovers device information associated with a peer network device present in an untrusted domain that is connected through a first link directly connecting a first interface of the network device to a first interface of the peer network device, and authenticates the peer network device while allowing at least some network traffic to continue to be transmitted through the first interface.
- the network device establishes a secure session between the network device and the peer network device over the first link coupling the first interface of the network device to the first interface of the peer network device when the peer network device is successfully authenticated.
- the network device allows the first link to operate as part of a single aggregated logical link, including a second link coupling a second interface of the network device to a second interface of the peer network device.
- the network device may use a Link Layer Discovery Protocol (LLDP) for discovering a peer network device and discover the device information, which includes a hostname of the peer network device, an address of the peer network device, or a capability of the peer network device.
- LLDP Link Layer Discovery Protocol
- the network device determines whether the peer network device is known to the network device as a result of having a previously validated peering session with the network device via the second link.
- the information indicative of the previously validated peering session may be maintained within a database accessible to the network device.
- the network device may use a challenge-response authentication mechanism for authenticating the peer device.
- the network device when there is no existing peering session, the network device establishes a Datagram Transport Layer Security (DTLS) connection between the network device and the peer network device via the first link.
- DTLS Datagram Transport Layer Security
- the network device receives a signed certificate from the peer network device via the DTLS connection and confirms if the signed certificate is from a trusted certificate authority.
- a secure session is established, and the first link is allowed to be aggregated with the second link to form the single aggregated logical link.
- Other links between the network device and the peer network device may similarly be aggregated if authenticated by challenge-response based authentication or DTLS authentication.
- the network device and the peer network device selectively encrypts packets transmitted on the single aggregated logical link.
- the selectively encrypted packets include control packets.
- FIG. 1 A conceptually illustrates an enterprise network in which link aggregation is performed in accordance with an embodiment of the present disclosure.
- FIG. 1 B illustrates a peer device becoming part of a secure domain in accordance with an embodiment of the present disclosure.
- FIG. 2 illustrates the functional modules of a secure link aggregation system in accordance with an embodiment of the present disclosure.
- FIG. 3 is a block diagram illustrating link aggregation in accordance with an embodiment of the present disclosure.
- FIG. 4 is a state diagram illustrating various states of a peer network device maintained by a local network device in accordance with an embodiment of the present disclosure.
- FIG. 5 is a block diagram illustrating device discovery in accordance with an embodiment of the present disclosure.
- FIG. 6 is a flow diagram illustrating secure link aggregation processing in accordance with an embodiment of the present disclosure.
- FIG. 7 illustrates an exemplary computer system in which or with which embodiments of the present invention may be utilized.
- link aggregation is extended to have a secured mode in which each link within the aggregate authenticates its peer prior to allowing the link to become active within the aggregate.
- IEEE Institute of Electrical and Electronics Engineers
- 802.X.2010 Port-Based Network Access Control
- MACsec IEEE 802.1AE
- EAP Extensible Authentication Protocol
- each of these methods has its limitations. For example, some of these approaches require everything transmitted on the link to be encrypted and/or disable the port on which the peer being authenticated until the authentication has been completed. The former cannot be used when one of the network devices is incapable of supporting full wire encryption and the latter may disrupt existing traffic traversing the port.
- Embodiments of the present invention include various steps, which will be described below.
- the steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps.
- steps may be performed by a combination of hardware, software, firmware, and/or by human operators.
- Embodiments of the present invention may be provided as a computer program product, which may include a machine-readable storage medium tangibly embodying thereon instructions, which may be used to program the computer (or other electronic devices) to perform a process.
- the machine-readable medium may include, but is not limited to, fixed (hard) drives, magnetic tape, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, semiconductor memories, such as ROMs, PROMs, random access memories (RAMs), programmable read-only memories (PROMs), erasable PROMs (EPROMs), electrically erasable PROMs (EEPROMs), flash memory, magnetic or optical cards, or other types of media/machine-readable medium suitable for storing electronic instructions (e.g., computer programming code, such as software or firmware).
- An apparatus for practicing various embodiments of the present invention may involve one or more computers (or one or more processors within the single computer) and storage systems containing or having network access to a computer program(s) coded in accordance with various methods described herein, and the method steps of the invention could be accomplished by modules, routines, subroutines, or subparts of a computer program product.
- connection or coupling and related terms are used in an operational sense and are not necessarily limited to a direct connection or coupling.
- two devices may be coupled directly, or via one or more intermediary media or devices.
- devices may be coupled in such a way that information can be passed therebetween, while not sharing any physical connection with one another.
- connection or coupling exists in accordance with the aforementioned definition.
- a “network device” generally refers to a Layer 2 device or appliance in virtual or physical form. Some network devices may be implemented as general-purpose computers or servers with appropriate software operable to perform Layer 2 functionality. Other network devices may also include custom hardware (e.g., one or more custom Application-Specific Integrated Circuits (ASICs)). appliances). Non-limiting examples of a network device include a Layer 2 switch, a bridge, a Wireless Local Area Network (WLAN) Access Point (AP), and a router.
- WLAN Wireless Local Area Network
- AP Wireless Local Area Network
- FIG. 1 A conceptually illustrates an enterprise network 100 in which link aggregation is performed in accordance with an embodiment of the present disclosure.
- the enterprise network 100 is logically divided into a secured domain 102 having network devices 104 a - c that trust each other and an unsecured domain 106 having network devices, for example, network device 108 , that is not trusted by any of the network devices 104 a - c of the secured domain 102 .
- network devices peer with partners they trust and can communicate safely once the trust is established. Any untrusted device, for example, network device 108 remains in the untrusted domain 106 until authenticated and peered with at-least one network device of the secured domain 102 .
- the network device 108 In order for a peer network device 108 to be connected to the secured domain 102 , the network device 108 establishes a trust relationship with its peer by exchanging certificates issued from a trusted certificate authority or certification authority (CA) 110 . Once mutual trust is established, the network devices form a single secure fabric domain, as shown in FIG. 1 B .
- CA certification authority
- a link aggregation control protocol may use a layer 2 neighbor discovery protocol (e.g., Link Layer Discovery Protocol (LLDP)) to authenticate and establish a secure session with the peer (e.g., network device 104 c and peer network device 108 ). Only when the peer, for example, the peer network device 108 , is validated, links 112 a - b between the network device 104 c and network device 108 are allowed to become active members of the aggregate 112 .
- LLDP Link Layer Discovery Protocol
- the network devices 104 c may perform initial detection of peer network device 108 via LLDP.
- LLDP works as the foundation of device detection, peer authentication, and encryption negotiation.
- the network device 104 c may use LLDP to determine whether the peer is known to it.
- Various authentication approaches may be used individually or in combination as described further below.
- a first authentication approach involving the use of a DTLS session through which both sides may confirm the other has a properly signed certificate from a trusted CA 110 , may be used when no validated peering sessions exist between the peers for any links.
- a second authentication approach involving a simple challenge-reply based authentication method may be used to confirm the peer has a valid key pair from a trusted CA 110 , which may be confirmed by sending a set of data to be signed by the peer.
- the simple challenge-reply based authentication method may be used in both scenarios without requiring a full DTLS session.
- a trusted relationship between the network device 104 c and the peer network device 108 can be used to establish an initial trust and initiate the link aggregation.
- the network device 104 c may establish a DTLS session with the peer network device 108 via the link 112 a and the devices may exchange respective signed certificates via the DTLS session.
- a trusted CA 110 which may also be referred to simply as a CA
- an authenticated session may be established between the network device 104 c and the peer network device 108 and information regarding the authenticated session may be stored in a local database maintained by the network device 104 c .
- link 112 a it is now permissible for link 112 a to be made an active member of a LAG.
- a parallel authentication process may also be performed by the peer 108 .
- the network device 104 c may consider the peer network device 108 as known when any link (e.g., link 112 a ) between the network device 104 c and the peer network device 108 has a validated peering session (e.g., an encrypted session that may be tracked in a database keyed by the LLDP peer's serial number).
- a validated peering session e.g., an encrypted session that may be tracked in a database keyed by the LLDP peer's serial number.
- the network device 104 c uses the challenge-reply (which may also be referred to herein as challenge-response) based authentication method to validate the peer network device 108 .
- challenge-reply which may also be referred to herein as challenge-response
- the network device 104 c may use LLDP for validating the fact that the peer network device is a recognized peer by tunneling the challenge-reply messages or DTLS session within an organizationally specific type length value (TLV) section of the LLDP frame.
- TLV may be limited to a maximum of 507 bytes of data per packet, and data may be sent across multiple sequential packets. As no reordering or loss is expected, any loss would result in authentication failure.
- the network device 104 c may consider the session between the network device 104 c and the peer network device 108 as authenticated when a peer network device 108 is verified.
- the network device 104 c may establish an encrypted session with the peer network device 108 .
- Each of the network devices 104 a - c may maintain a list of authenticated sessions in a database keyed by the LLDP peer's serial number. According to one embodiment, only one authenticated session per peer is established and maintained in the database and additional links may be added via the challenge-reply mechanism.
- a second link (e.g., link 112 b ) between peer devices (e.g., network device 104 c and peer network device 108 ) can be added to the aggregate via a challenge-reply mechanism, if there is an existing session between the peer devices.
- a link is considered to be part of the aggregate only after the link is properly authenticated.
- LACP begins to encrypt and decrypt LACP packets on the authenticated link.
- the network devices 104 a - c may maintain in their respective databases information regarding DTLS sessions, which may be maintained per peer, for example, based on the peer's serial number.
- the proposed mechanism can handle multiple switch connections and Multi-Chassis LAG (MC-LAG) topologies.
- M-LAG Multi-Chassis LAG
- a network device may use other peer validation mechanisms.
- the network device 104 c instead of using a full DTLS session for purposes of performing peer authentication, may use a simple challenge and reply method for validating a peer network device 108 .
- the network device 104 c may send a set of data to be signed by the peer network device 108 and use the signed data along with the public signing certificate to verify that the peer network device has a valid key pair from the trusted CA 110 .
- the links 112 a - b between the network device 104 c and the network device 108 can be aggregated, and network traffic exchanged therebetween can be selectively transmitted in encrypted form.
- all traffic sent on the links may be encrypted or encryption may be limited to control packets.
- the peers may encrypt only particular types of packets (e.g., control traffic (Spanning Tree Protocol (STP), LACP, Open Shortest Path First (OSPF), etc.), user traffic, packets associated with a particular protocol, etc.)
- the peer network device 108 remains in an unauthenticated state if it fails the challenge-reply based authentication, and may be periodically re-challenged.
- the network device 104 c may consider the peer network device 108 as a trusted peer.
- a network device 104 c present in a secure domain 102 may discover device information associated with a peer network device 108 having a first link (e.g., link 112 a ) directly connecting a first interface of the network device 104 c to a first interface of the peer network device 108 , and authenticate the peer network device 108 before aggregating the first link with a second link (e.g., link 112 b ) to form a single aggregated link 112 .
- the peer network device 108 until authenticated, is considered to be part of an unsecured domain 106 .
- Non-limiting examples of discovered device information may include a hostname, an address, a serial number, or a capability of the peer network device.
- the network device 104 c may use a layer 2 neighbor discovery protocol (e.g., LLDP) for discovery of the peer and its device information.
- LLDP layer 2 neighbor discovery protocol
- the network device 104 c may authenticate the peer network device 108 while allowing at least some network traffic to continue to be transmitted through the first interface.
- the network device 104 c establishes a secure session between the network device 104 c and the peer network device 108 over the first link coupling the first interface of the network device 104 c to the first interface of the peer network device 108 when the peer network device 108 is successfully authenticated and allows the first link to operate as part of a single aggregated logical link including a second link 112 b coupling a second interface of the network device to a second interface of the peer network device.
- the network device 104 c may determine whether the peer network device 108 is known to the network device 104 c as a result of having a previously validated peering session with the peer network device 108 via the second link 112 b .
- the information indicative of the previously validated peering session may be maintained within a database accessible to the network device.
- the network device may use a simple challenge-response authentication mechanism for authenticating the peer device.
- the devices may selectively encrypt packets transmitted via the single aggregated logical link.
- FIG. 1 B illustrates a peer device 108 becoming part of a secure domain in accordance with an embodiment of the present disclosure.
- the peer network device 108 becomes part of secured domain 102 once the peer network device 108 is authenticated and the links between the network device 104 c and the peer network device 108 are aggregated and secured.
- FIG. 2 illustrates the functional modules of a secure link aggregation system 200 in accordance with an embodiment of the present disclosure.
- the system 200 may be implemented within a network device (e.g., network device 104 , 108 , 302 , 304 , and/or 502 ) and includes a device discovery module 202 operable to discover by a processing resource of a network device within a secure domain, device information associated with a peer network device in an untrusted domain.
- the device discovery module 202 may use LLDP to discover the peer network device, where the first interface of the network device is directly connected to the first interface of the peer network device.
- the system 200 includes a peer authentication module 204 operable to authenticate the peer network device while allowing at least some network traffic to continue to be transmitted through the first interface, and a secure session establishment module 206 operable to establish a secure session between the network device and the peer network device over a first link coupling the first interface of the network device to the first interface of the peer network device when the peer network device is successfully authenticated.
- the system 200 further includes a link aggregation module 208 configured to allow the first link to operate as part of a single aggregated logical link, including a second link coupling a second interface of the network device to a second interface of the peer network device.
- the peer authentication module 204 at the network device may use LLDP for authenticating a peer network device.
- the peer authentication module 204 at the network device checks the existence of an established session between the network device and the peer network device by referring to a database storing information regarding existing authenticated sessions.
- a secure ink aggregation system 200 may store a serial number of a peer network devices with which it has an established secure session.
- the peer authentication module 204 determines whether the peer network device is known to the network device by checking the existence of a validated peering session. When an existing peering session between the network device and the peer network device is found in the database, the peer network device is considered to be authenticated. In the absence of a peering session between the network device and the peer network device or when a predefined time duration has lapsed for the existing peering session, module 204 may make use of a DTLS session with the peer network device to perform peer authentication.
- the secure session establishment module 206 facilitates the negotiation of an encryption mechanism between the network device and the peer network device and creates the secure session between the network device and the peer network device.
- the link aggregation module 208 is operable to aggregate a link between the network device and the peer network device with one or more other links between the network device and the peer network device to form a LAG. For each discovered link between the network device and the peer network device, the system 200 may check if there is an existing peer relationship between the network device and the peer network device. If there an existing peer relationship, module 208 may perform a challenge-response based authentication for such subsequent links, and in response to successful completion of the challenge-response based authentication allow the newly authorized link to be aggregated into the LAG.
- the system 200 may establish a DTLS session with the peer network device to perform peer authentication, for example, by exchanging and validating respective signed certificates via the DTLS session as described above.
- the LACP begins to recognize the first link as a valid member of the link aggregation group. At this point, LACP may begin to encrypt all LACP packet on the authenticated link. As LACP packets are supposed to be fairly static, random data may be added to each packet in order to produce a constantly changing encryption result.
- the system 200 maintains a DTLS session per peer, which allows the handling of multiple switch connections and MC-LAG topologies. When the network device or peer network device receives invalid data, LACP may keep the member down and may not treat the link between the network device and the peer network device as secure.
- MSL maximum segment lifetime
- system 200 enables link aggregation between a secured network device of a secured fabric domain and a network device present outside the secured fabric domain.
- the system discovers the presence of a peer network device in an untrusted domain using Link Layer Discovery Protocol (LLDP), authenticates a peer relationship between a network device and the peer network device, establishes a secure session between the network device and the peer network device based on the authentication result, and enables aggregation of one or more links between the network device and the peer network device if the secure session between the secured network device and the network device is established.
- LLDP Link Layer Discovery Protocol
- FIG. 3 is a block diagram illustrating link aggregation in accordance with an embodiment of the present disclosure.
- a link aggregation group (LAG) 306 can be created by aggregating existing links between two network devices, for example, between network device 302 and network device 304 .
- a link 306 a connecting a first interface (e.g., Port_1) of network device 302 with a first interface (e.g., NIC-1) of the network device 304 may be aggregated to be part of the LAG 306 based on a peer authentication process involving the use of a DTLS session or a challenge-response authentication approach.
- the link 306 a may allowed to be aggregated based on the challenge-response authentication approach when there is an existing peering relation between the network device 302 and the network device 304 via another link (e.g., link 306 b ).
- another link e.g., link 306 b
- the link 306 a can be easily aggregated using the challenge-response authentication.
- secure link aggregation allows combining multiple network connections in parallel between two mutually authenticated network devices to increase throughput beyond what a single connection could sustain, and provides redundancy in case one of the links fails.
- FIG. 4 is a state diagram 400 illustrating various states of a peer network device maintained by a local network device in accordance with an embodiment of the present disclosure.
- the local network device e.g., network device 104 c
- the local network device within a secure fabric domain may maintain a state machine for each direct link (e.g., links 112 a - b ) between the local network device and each peer network device (e.g., network device 108 ).
- the local network device may maintain a single state machine for each peer network device to reflect a current state of a session with the peer network device.
- the local network device may consider the link state to be in an unauthenticated state 402 .
- peer authentication for the link at issue is attempted through a DTLS session and the link state transitions to an authenticating state 404 . While the peer authentication is in process, the link state remains in the authenticating state 404 .
- the local network device may continue to send and receive some traffic via interfaces associated with links on which a peer network device is being authenticated. That is, interfaces remain active and are not disabled during peer authentication processing.
- this mitigates potential disruption of existing traffic traversing the interfaces.
- the network device may forego making use of a full DTLS session for performing peer authentication for the link at issue and may instead use a simple challenge-response based authentication approach.
- the link at issue is down, and/or the peer network device fails the challenge-response based authentication for the link at issue, the link state may transition back to the unauthenticated state 402 and the peer network device may be periodically re-challenged.
- the link state transitions to an authenticated state 406 .
- the peers are periodically rekeyed and the link states remains in the authenticated state 406 .
- each subsequent link between the local network device and the peer network device can be added via the challenge-response based authentication approach.
- the link state transitions from the authenticated state 406 back to the unauthenticated state 402 after the expiration of a preconfigured timeout period and/or when the link goes down.
- FIG. 5 is a block diagram 500 illustrating device discovery in accordance with an embodiment of the present disclosure.
- LLDP is enabled appropriate interfaces/ports of network devices 502 a - d to facilitate discovery of each other and collection of device information.
- device information include a hostname, an address (e.g., an Media Access Control (MAC) address), a serial number and one or more capabilities (e.g., supported system capabilities (the primary function of the device, for example, a bridge, WLAN AP, or router), enabled system capabilities, port speed capabilities, aggregation capability, etc.) of a network device.
- MAC Media Access Control
- Network devices 502 a - b send LLDP advertisements to each other advertising their respective device information via each of their respective LLDP-enabled interfaces and the recipient network devices store the received device information in respective management information base (MIB) databases (e.g., internal MIB 506 ). While only one internal MIB 506 is shown it is to be appreciated that each network device 502 a - d may have an associated internal MIB.
- the internal MIB 506 may include a local system MIB (not shown) and a remote system MIB (not shown).
- the local system MIB may store device information for the local device (the device's own information) and the remote system MIB may store device information gathered via LLDP advertisements received from the peer network devices. Responsive to discovering a peer network device on a particular link a network device may authenticate the peer network device using the authentication mechanism suggested below.
- modules 202 , 204 , 206 , and 208 may be implemented in the form of executable instructions stored on a machine readable medium and executed by a processing resource (e.g., a microcontroller, a microprocessor, central processing unit core(s), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), and the like) and/or in the form of other types of electronic circuitry.
- a processing resource e.g., a microcontroller, a microprocessor, central processing unit core(s), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), and the like
- the processing may be performed by one or more virtual or physical computer systems of various forms, such as the computer system described with reference to FIG. 7 below.
- FIG. 6 is a flow diagram illustrating secure link aggregation processing in accordance with an embodiment of the present disclosure.
- a processing resource of a network device e.g., network device 104 c within a secure domain discovers device information associated with a peer network device (e.g., peer network device 108 ) in an untrusted domain.
- this discovery process involves receipt of a layer 2 neighbor discovery protocol message (e.g., an LLDP advertisement) from the peer network device on a first link (e.g., link 112 a ) directly coupling a first interface of the network device with a first interface of the peer network device.
- a layer 2 neighbor discovery protocol message e.g., an LLDP advertisement
- the layer 2 neighbor discover protocol may include device information (e.g., a host name, an address, and a serial number) of the peer network device.
- the device information may be stored within a local MIB (e.g., internal MIB 506 ) associated with the network device.
- the processing resource authenticates the peer network device while allowing at least some network traffic to continue to be transmitted through the first interface.
- one or more authentication approaches may be used individually or in combination.
- a first peer authentication approach may involve the use of a DTLS session in which the network device confirms the peer network device has a properly signed certificate from a trusted CA (e.g., CA 110 ).
- a second peer authentication approach may involve a simple challenge-reply based authentication approach to confirm the peer network device has a valid key pair from the trusted CA, which may be confirmed by sending a set of data to be signed by the peer network device.
- the first peer authentication approach is used when no validated peering sessions exist between the network device and the peer network device for any direct links therebetween and the second peer authentication approach is used, when a validated peering session already exists between the peers for at least one link.
- the first peer authentication approach may be used regardless of the existence of a validated peering session.
- the second peer authentication approach may be used regardless of the existence of a validated peering session.
- the processing resource establishes a secure session between the network device and the peer network device over the first link.
- LACP begins to encrypt and decrypt all LACP packets on the authenticated link.
- Information regarding the authenticated session (also referred to herein as the validating peering session) may be stored in a database maintained by the network device. For example, a single DTLS session may be maintained per peer and keyed by the LLDP peer's serial number.
- encryption may be selectively performed based on one or more criteria (e.g., a type of packet, a protocol associated with the packet, etc.).
- the processing resource allows the first link to operate as part of a single aggregated logical link (e.g., LAG 112 ) including a second link (e.g., link 112 b ) coupling a second interface of the network device to a second interface of the peer network device.
- the network device marks the first link as an active member of the LAG.
- network traffic including data packets and control packets
- network traffic can be selectively transmitted in encrypted form using a negotiated encryption mechanism between the network device and peer network device.
- particular types of packets e.g., control traffic (STP, LACP, OSPF, etc.) vs. user traffic
- STP control traffic
- LACP LACP
- OSPF OSPF
- the approach described herein can be extended to protect other legacy protocols that do not natively support encryption.
- Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to example embodiments described herein with appropriate standard computer hardware to execute the code contained therein.
- An apparatus for practicing various example embodiments described herein may involve one or more computing elements or computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of various example embodiments described herein may be accomplished by modules, routines, subroutines, or subparts of a computer program product.
- FIG. 7 illustrates an exemplary computer system in which or with which embodiments of the present invention may be utilized.
- a computer system includes an external storage device 740 , a bus 730 , a main memory 715 , a read-only memory 720 , a mass storage device 725 , a communication port 710 , and one or more processing resources (e.g., processing circuitry 705 ).
- Computer system 700 may represent some portion of a network device (e.g., network device 104 , 108 , 302 , 304 , and/or 502 ).
- computer system 700 may include more than one processor and communication ports 710 .
- processing circuitry 705 include, but are not limited to, an Intel® Itanium® or Itanium 2 processor(s), or AMD® Opteron® or Athlon MP® processor(s), Motorola® lines of processors, FortiSOCTM system on chip processors or other future processors.
- Processing circuitry 705 may include various modules associated with embodiments of the present invention.
- Communication port 710 can be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports.
- Communication port 710 may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects.
- LAN Local Area Network
- WAN Wide Area Network
- Memory 715 can be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art.
- Read-Only Memory 720 can be any static storage device(s) e.g., but not limited to, a Programmable Read-Only Memory (PROM) chips for storing static information e.g. start-up or BIOS instructions for processing circuitry 705 .
- PROM Programmable Read-Only Memory
- Mass storage 725 may be any current or future mass storage solution, which can be used to store information and/or instructions.
- Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), e.g. those available from Seagate (e.g., the Seagate Barracuda 7200 family) or Hitachi (e.g., the Hitachi Deskstar 7K1000), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks (e.g., SATA arrays), available from various vendors including Dot Hill Systems Corp., LaCie, Nexsan Technologies, Inc. and Enhance Technology, Inc.
- PATA Parallel Advanced Technology Attachment
- SATA Serial Advanced Technology Attachment
- SSD Universal Serial Bus
- Firewire interfaces e.g.,
- Bus 730 communicatively couples processing circuitry 705 with the other memory, storage, and communication blocks.
- Bus 730 can be, e.g. a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), USB or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects processing circuitry 705 to a software system.
- PCI Peripheral Component Interconnect
- PCI-X PCI Extended
- SCSI Small Computer System Interface
- FFB front side bus
Abstract
Systems and methods are for securing link aggregation are provided. According to an embodiment, a network device in a secure domain discovers device information associated with a peer network device in an untrusted domain that is connected through a first link directly connecting a first interface of the network device to a first interface of the peer network device, and authenticates the peer while allowing at least some network traffic to continue to be transmitted through the first interface. The network device establishes a secure session between the network device and the peer over the first link when the peer network device is successfully authenticated. The network device then allows the first link to operate as part of a single aggregated logical link, including a second link coupling a second interface of the network device to a second interface of the peer network device.
Description
- This application is a continuation of U.S. patent application Ser. No. 17/039,853 filed on Sep. 30, 2020, which is hereby incorporated by reference in its entirety for all purposes.
- Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever. Copyright © 2020, Fortinet, Inc.
- Embodiments of the present invention generally relate to network security and link aggregation. In particular, embodiments of the present invention relate to link aggregation control protocol (LACP) and verification of peer devices before allowing links to become active within a link aggregation group (LAG).
- Link aggregation allows multiple physical links between two end-points to be aggregated together to form a LAG by combining multiple network interfaces into a single logical interface to increase throughput and provide redundancy in case of link failures. A Media Access Control (MAC) client can treat the LAG (which may also be referred to as a virtual link or bundle) as a single logical link. Link aggregation provides network redundancy by load-balancing traffic across all available links. If one of the links fails, the system automatically load-balances traffic across all remaining links.
- In networks that support link aggregation, directly-connected network devices that also implement LACP (which may be referred to herein as link peers or simply peers) can automatically aggregate links together based on a set of specific properties negotiated, for example, via LACP.
- Systems and methods are described for securing link aggregation. According to an embodiment, a network device present in a secure domain discovers device information associated with a peer network device present in an untrusted domain that is connected through a first link directly connecting a first interface of the network device to a first interface of the peer network device, and authenticates the peer network device while allowing at least some network traffic to continue to be transmitted through the first interface. The network device establishes a secure session between the network device and the peer network device over the first link coupling the first interface of the network device to the first interface of the peer network device when the peer network device is successfully authenticated. The network device allows the first link to operate as part of a single aggregated logical link, including a second link coupling a second interface of the network device to a second interface of the peer network device.
- In an embodiment, the network device may use a Link Layer Discovery Protocol (LLDP) for discovering a peer network device and discover the device information, which includes a hostname of the peer network device, an address of the peer network device, or a capability of the peer network device.
- The network device determines whether the peer network device is known to the network device as a result of having a previously validated peering session with the network device via the second link. In an embodiment, the information indicative of the previously validated peering session may be maintained within a database accessible to the network device. In an embodiment, the network device may use a challenge-response authentication mechanism for authenticating the peer device.
- In an embodiment, when there is no existing peering session, the network device establishes a Datagram Transport Layer Security (DTLS) connection between the network device and the peer network device via the first link. The network device receives a signed certificate from the peer network device via the DTLS connection and confirms if the signed certificate is from a trusted certificate authority.
- Once the peer network device is authenticated, a secure session is established, and the first link is allowed to be aggregated with the second link to form the single aggregated logical link. Other links between the network device and the peer network device may similarly be aggregated if authenticated by challenge-response based authentication or DTLS authentication.
- In an embodiment, the network device and the peer network device selectively encrypts packets transmitted on the single aggregated logical link. The selectively encrypted packets include control packets.
- Other features of embodiments of the present disclosure will be apparent from accompanying drawings and detailed description that follows.
- In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description applies to any one of the similar components having the same first reference label irrespective of the second reference label.
-
FIG. 1A conceptually illustrates an enterprise network in which link aggregation is performed in accordance with an embodiment of the present disclosure. -
FIG. 1B illustrates a peer device becoming part of a secure domain in accordance with an embodiment of the present disclosure. -
FIG. 2 illustrates the functional modules of a secure link aggregation system in accordance with an embodiment of the present disclosure. -
FIG. 3 is a block diagram illustrating link aggregation in accordance with an embodiment of the present disclosure. -
FIG. 4 is a state diagram illustrating various states of a peer network device maintained by a local network device in accordance with an embodiment of the present disclosure. -
FIG. 5 is a block diagram illustrating device discovery in accordance with an embodiment of the present disclosure. -
FIG. 6 is a flow diagram illustrating secure link aggregation processing in accordance with an embodiment of the present disclosure. -
FIG. 7 illustrates an exemplary computer system in which or with which embodiments of the present invention may be utilized. - Systems and methods are described for securing link aggregation. In embodiments described herein, link aggregation is extended to have a secured mode in which each link within the aggregate authenticates its peer prior to allowing the link to become active within the aggregate. There are several existing methods, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.X.2010 (Port-Based Network Access Control), IEEE 802.1AE (MACsec), and Extensible Authentication Protocol (EAP) that can be used for verifying the identity of the network device before link aggregation between the network device and the secured network device. However, each of these methods has its limitations. For example, some of these approaches require everything transmitted on the link to be encrypted and/or disable the port on which the peer being authenticated until the authentication has been completed. The former cannot be used when one of the network devices is incapable of supporting full wire encryption and the latter may disrupt existing traffic traversing the port.
- Embodiments of the present invention include various steps, which will be described below. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, steps may be performed by a combination of hardware, software, firmware, and/or by human operators.
- Embodiments of the present invention may be provided as a computer program product, which may include a machine-readable storage medium tangibly embodying thereon instructions, which may be used to program the computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, fixed (hard) drives, magnetic tape, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, semiconductor memories, such as ROMs, PROMs, random access memories (RAMs), programmable read-only memories (PROMs), erasable PROMs (EPROMs), electrically erasable PROMs (EEPROMs), flash memory, magnetic or optical cards, or other types of media/machine-readable medium suitable for storing electronic instructions (e.g., computer programming code, such as software or firmware).
- Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present invention with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present invention may involve one or more computers (or one or more processors within the single computer) and storage systems containing or having network access to a computer program(s) coded in accordance with various methods described herein, and the method steps of the invention could be accomplished by modules, routines, subroutines, or subparts of a computer program product.
- In the following description, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be apparent, however, to one skilled in the art that embodiments described herein may be practiced without some of these specific details
- Brief definitions of terms used throughout this application are given below.
- The terms “connected” or “coupled” and related terms are used in an operational sense and are not necessarily limited to a direct connection or coupling. Thus, for example, two devices may be coupled directly, or via one or more intermediary media or devices. As another example, devices may be coupled in such a way that information can be passed therebetween, while not sharing any physical connection with one another. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate a variety of ways in which connection or coupling exists in accordance with the aforementioned definition.
- If the specification states a component or feature “may,” “can,” “could,” or “might” be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.
- As used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
- The phrases “in an embodiment,” “according to one embodiment,” and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one embodiment of the present disclosure and may be included in more than one embodiment of the present disclosure. Importantly, such phrases do not necessarily refer to the same embodiment.
- As used herein, a “network device” generally refers to a
Layer 2 device or appliance in virtual or physical form. Some network devices may be implemented as general-purpose computers or servers with appropriate software operable to performLayer 2 functionality. Other network devices may also include custom hardware (e.g., one or more custom Application-Specific Integrated Circuits (ASICs)). appliances). Non-limiting examples of a network device include aLayer 2 switch, a bridge, a Wireless Local Area Network (WLAN) Access Point (AP), and a router. -
FIG. 1A conceptually illustrates anenterprise network 100 in which link aggregation is performed in accordance with an embodiment of the present disclosure. In the context of the present example, theenterprise network 100 is logically divided into asecured domain 102 having network devices 104 a-c that trust each other and anunsecured domain 106 having network devices, for example,network device 108, that is not trusted by any of the network devices 104 a-c of thesecured domain 102. In thesecured domain 102, network devices peer with partners they trust and can communicate safely once the trust is established. Any untrusted device, for example,network device 108 remains in theuntrusted domain 106 until authenticated and peered with at-least one network device of thesecured domain 102. In order for apeer network device 108 to be connected to thesecured domain 102, thenetwork device 108 establishes a trust relationship with its peer by exchanging certificates issued from a trusted certificate authority or certification authority (CA) 110. Once mutual trust is established, the network devices form a single secure fabric domain, as shown inFIG. 1B . - For enabling secure link aggregation between a network device of
secured domain 102, and network device 108 (which may also be referred to as peer network device 108) that may be present inunsecured domain 106, each link within the aggregate is authenticated. A link aggregation control protocol (LACP) may use alayer 2 neighbor discovery protocol (e.g., Link Layer Discovery Protocol (LLDP)) to authenticate and establish a secure session with the peer (e.g.,network device 104 c and peer network device 108). Only when the peer, for example, thepeer network device 108, is validated,links 112 a-b between thenetwork device 104 c andnetwork device 108 are allowed to become active members of theaggregate 112. - In an embodiment, the
network devices 104 c may perform initial detection ofpeer network device 108 via LLDP. LLDP works as the foundation of device detection, peer authentication, and encryption negotiation. Thenetwork device 104 c may use LLDP to determine whether the peer is known to it. Various authentication approaches may be used individually or in combination as described further below. In one embodiment, a first authentication approach, involving the use of a DTLS session through which both sides may confirm the other has a properly signed certificate from a trustedCA 110, may be used when no validated peering sessions exist between the peers for any links. In one embodiment, when a validating peering session already exists between the peers for at least one link, a second authentication approach, involving a simple challenge-reply based authentication method may be used to confirm the peer has a valid key pair from a trustedCA 110, which may be confirmed by sending a set of data to be signed by the peer. In another embodiment, the simple challenge-reply based authentication method may be used in both scenarios without requiring a full DTLS session. For purposes of aggregating links between thenetwork device 104 a and thepeer network device 108, a trusted relationship between thenetwork device 104 c and thepeer network device 108 can be used to establish an initial trust and initiate the link aggregation. - According to one embodiment, responsive to discovery of the
peer network device 108 on a first link (e.g., link 112 a), thenetwork device 104 c may establish a DTLS session with thepeer network device 108 via thelink 112 a and the devices may exchange respective signed certificates via the DTLS session. When the signed certificate received from thepeer network device 108 is confirmed to be from a trusted CA 110 (which may also be referred to simply as a CA), an authenticated session may be established between thenetwork device 104 c and thepeer network device 108 and information regarding the authenticated session may be stored in a local database maintained by thenetwork device 104 c. At this point, it is now permissible forlink 112 a to be made an active member of a LAG. As those skilled in the art will appreciate, a parallel authentication process may also be performed by thepeer 108. - In one embodiment, once at least one validated peering sessions exists between the peers for any link (e.g., link 112 a), subsequent links with the same peer may be authenticated by performing a simple challenge and response authentication. For example, the
network device 104 c may consider thepeer network device 108 as known when any link (e.g., link 112 a) between thenetwork device 104 c and thepeer network device 108 has a validated peering session (e.g., an encrypted session that may be tracked in a database keyed by the LLDP peer's serial number). In one embodiment, whennetwork device 104 c determines there is an existing valid peering session between thenetwork device 104 c and thepeer network device 108, thenetwork device 104 c, then uses the challenge-reply (which may also be referred to herein as challenge-response) based authentication method to validate thepeer network device 108. - In an embodiment, the
network device 104 c may use LLDP for validating the fact that the peer network device is a recognized peer by tunneling the challenge-reply messages or DTLS session within an organizationally specific type length value (TLV) section of the LLDP frame. The TLV may be limited to a maximum of 507 bytes of data per packet, and data may be sent across multiple sequential packets. As no reordering or loss is expected, any loss would result in authentication failure. - The
network device 104 c may consider the session between thenetwork device 104 c and thepeer network device 108 as authenticated when apeer network device 108 is verified. Thenetwork device 104 c may establish an encrypted session with thepeer network device 108. Each of the network devices 104 a-c may maintain a list of authenticated sessions in a database keyed by the LLDP peer's serial number. According to one embodiment, only one authenticated session per peer is established and maintained in the database and additional links may be added via the challenge-reply mechanism. For example, a second link (e.g., link 112 b) between peer devices (e.g.,network device 104 c and peer network device 108) can be added to the aggregate via a challenge-reply mechanism, if there is an existing session between the peer devices. In an embodiment, a link is considered to be part of the aggregate only after the link is properly authenticated. At this point, LACP begins to encrypt and decrypt LACP packets on the authenticated link. As LACP packets tend to be fairly static, random data may be added to each packet in order to produce constantly changing encryption results. The network devices 104 a-c may maintain in their respective databases information regarding DTLS sessions, which may be maintained per peer, for example, based on the peer's serial number. The proposed mechanism can handle multiple switch connections and Multi-Chassis LAG (MC-LAG) topologies. - As noted above, depending upon the particular implementation, a network device (e.g.,
network device 104 c) may use other peer validation mechanisms. In one embodiment, thenetwork device 104 c, instead of using a full DTLS session for purposes of performing peer authentication, may use a simple challenge and reply method for validating apeer network device 108. For example, thenetwork device 104 c may send a set of data to be signed by thepeer network device 108 and use the signed data along with the public signing certificate to verify that the peer network device has a valid key pair from the trustedCA 110. Once authenticated, thelinks 112 a-b between thenetwork device 104 c and thenetwork device 108 can be aggregated, and network traffic exchanged therebetween can be selectively transmitted in encrypted form. For example, all traffic sent on the links may be encrypted or encryption may be limited to control packets. On a system in which full wire encryption is infeasible, not possible, or simply not desired, the peers may encrypt only particular types of packets (e.g., control traffic (Spanning Tree Protocol (STP), LACP, Open Shortest Path First (OSPF), etc.), user traffic, packets associated with a particular protocol, etc.) - In an embodiment, the
peer network device 108 remains in an unauthenticated state if it fails the challenge-reply based authentication, and may be periodically re-challenged. When the challenge-reply authentication is completed, thenetwork device 104 c may consider thepeer network device 108 as a trusted peer. - In an embodiment, a
network device 104 c present in asecure domain 102 may discover device information associated with apeer network device 108 having a first link (e.g., link 112 a) directly connecting a first interface of thenetwork device 104 c to a first interface of thepeer network device 108, and authenticate thepeer network device 108 before aggregating the first link with a second link (e.g., link 112 b) to form a single aggregatedlink 112. Thepeer network device 108, until authenticated, is considered to be part of anunsecured domain 106. Non-limiting examples of discovered device information may include a hostname, an address, a serial number, or a capability of the peer network device. Thenetwork device 104 c may use alayer 2 neighbor discovery protocol (e.g., LLDP) for discovery of the peer and its device information. - In an embodiment, the
network device 104 c may authenticate thepeer network device 108 while allowing at least some network traffic to continue to be transmitted through the first interface. Thenetwork device 104 c establishes a secure session between thenetwork device 104 c and thepeer network device 108 over the first link coupling the first interface of thenetwork device 104 c to the first interface of thepeer network device 108 when thepeer network device 108 is successfully authenticated and allows the first link to operate as part of a single aggregated logical link including asecond link 112 b coupling a second interface of the network device to a second interface of the peer network device. - The
network device 104 c may determine whether thepeer network device 108 is known to thenetwork device 104 c as a result of having a previously validated peering session with thepeer network device 108 via thesecond link 112 b. In an embodiment, the information indicative of the previously validated peering session may be maintained within a database accessible to the network device. In an embodiment, due to the existing peering session with thepeer network device 108, the network device may use a simple challenge-response authentication mechanism for authenticating the peer device. In an embodiment, after all links (e.g.,links 112 a-b) between thenetwork device 104 c and thepeer network device 108 have been validated and made active members of a single aggregated logical link (e.g., LAG 112), the devices may selectively encrypt packets transmitted via the single aggregated logical link. -
FIG. 1B illustrates apeer device 108 becoming part of a secure domain in accordance with an embodiment of the present disclosure. Thepeer network device 108 becomes part ofsecured domain 102 once thepeer network device 108 is authenticated and the links between thenetwork device 104 c and thepeer network device 108 are aggregated and secured. -
FIG. 2 illustrates the functional modules of a securelink aggregation system 200 in accordance with an embodiment of the present disclosure. Thesystem 200 may be implemented within a network device (e.g.,network device device discovery module 202 operable to discover by a processing resource of a network device within a secure domain, device information associated with a peer network device in an untrusted domain. Thedevice discovery module 202 may use LLDP to discover the peer network device, where the first interface of the network device is directly connected to the first interface of the peer network device. Thesystem 200 includes apeer authentication module 204 operable to authenticate the peer network device while allowing at least some network traffic to continue to be transmitted through the first interface, and a securesession establishment module 206 operable to establish a secure session between the network device and the peer network device over a first link coupling the first interface of the network device to the first interface of the peer network device when the peer network device is successfully authenticated. Thesystem 200 further includes alink aggregation module 208 configured to allow the first link to operate as part of a single aggregated logical link, including a second link coupling a second interface of the network device to a second interface of the peer network device. - In an embodiment, the
peer authentication module 204 at the network device may use LLDP for authenticating a peer network device. Thepeer authentication module 204 at the network device checks the existence of an established session between the network device and the peer network device by referring to a database storing information regarding existing authenticated sessions. For example, a secureink aggregation system 200 may store a serial number of a peer network devices with which it has an established secure session. In some embodiments, thepeer authentication module 204 determines whether the peer network device is known to the network device by checking the existence of a validated peering session. When an existing peering session between the network device and the peer network device is found in the database, the peer network device is considered to be authenticated. In the absence of a peering session between the network device and the peer network device or when a predefined time duration has lapsed for the existing peering session,module 204 may make use of a DTLS session with the peer network device to perform peer authentication. - Once the peer network device is validated, the secure
session establishment module 206 facilitates the negotiation of an encryption mechanism between the network device and the peer network device and creates the secure session between the network device and the peer network device. - The
link aggregation module 208 is operable to aggregate a link between the network device and the peer network device with one or more other links between the network device and the peer network device to form a LAG. For each discovered link between the network device and the peer network device, thesystem 200 may check if there is an existing peer relationship between the network device and the peer network device. If there an existing peer relationship,module 208 may perform a challenge-response based authentication for such subsequent links, and in response to successful completion of the challenge-response based authentication allow the newly authorized link to be aggregated into the LAG. In an embodiment, where there is no existing peer relationship between the network device and the peer network device, thesystem 200 may establish a DTLS session with the peer network device to perform peer authentication, for example, by exchanging and validating respective signed certificates via the DTLS session as described above. - Once the link has been authenticated, the LACP begins to recognize the first link as a valid member of the link aggregation group. At this point, LACP may begin to encrypt all LACP packet on the authenticated link. As LACP packets are supposed to be fairly static, random data may be added to each packet in order to produce a constantly changing encryption result. In an embodiment, the
system 200 maintains a DTLS session per peer, which allows the handling of multiple switch connections and MC-LAG topologies. When the network device or peer network device receives invalid data, LACP may keep the member down and may not treat the link between the network device and the peer network device as secure. When a DTLS session is re-keyed, one side may have a new key, while the other side may still have an old key, this situation can be addressed by DTLS via its maximum segment lifetime (MSL), which may be assigned to each authenticated session. - In an embodiment,
system 200 enables link aggregation between a secured network device of a secured fabric domain and a network device present outside the secured fabric domain. The system discovers the presence of a peer network device in an untrusted domain using Link Layer Discovery Protocol (LLDP), authenticates a peer relationship between a network device and the peer network device, establishes a secure session between the network device and the peer network device based on the authentication result, and enables aggregation of one or more links between the network device and the peer network device if the secure session between the secured network device and the network device is established. -
FIG. 3 is a block diagram illustrating link aggregation in accordance with an embodiment of the present disclosure. In an embodiment, a link aggregation group (LAG) 306 can be created by aggregating existing links between two network devices, for example, betweennetwork device 302 andnetwork device 304. Alink 306 a connecting a first interface (e.g., Port_1) ofnetwork device 302 with a first interface (e.g., NIC-1) of thenetwork device 304 may be aggregated to be part of theLAG 306 based on a peer authentication process involving the use of a DTLS session or a challenge-response authentication approach. For example, thelink 306 a may allowed to be aggregated based on the challenge-response authentication approach when there is an existing peering relation between thenetwork device 302 and thenetwork device 304 via another link (e.g., link 306 b). As shown inFIG. 3 , if an existing peering session has previously been established via thelink 306 b, thelink 306 a can be easily aggregated using the challenge-response authentication. In this manner, secure link aggregation allows combining multiple network connections in parallel between two mutually authenticated network devices to increase throughput beyond what a single connection could sustain, and provides redundancy in case one of the links fails. -
FIG. 4 is a state diagram 400 illustrating various states of a peer network device maintained by a local network device in accordance with an embodiment of the present disclosure. Depending upon the particular implementation, the local network device (e.g.,network device 104 c) within a secure fabric domain may maintain a state machine for each direct link (e.g.,links 112 a-b) between the local network device and each peer network device (e.g., network device 108). Alternatively, the local network device may maintain a single state machine for each peer network device to reflect a current state of a session with the peer network device. - In the context of the present example, responsive to discovery of the peer network device on a link at issue (e.g., link 112 a) by the local network device, the local network device may consider the link state to be in an
unauthenticated state 402. - According to one embodiment, in a scenario in which there is no existing peering session between the local network device and the peer network device (e.g., there are no links between the peer network device and the local network device that are in an authenticated state 406), peer authentication for the link at issue is attempted through a DTLS session and the link state transitions to an authenticating
state 404. While the peer authentication is in process, the link state remains in the authenticatingstate 404. In contrast to other link aggregation approaches, in one embodiment, the local network device may continue to send and receive some traffic via interfaces associated with links on which a peer network device is being authenticated. That is, interfaces remain active and are not disabled during peer authentication processing. Advantageously, this mitigates potential disruption of existing traffic traversing the interfaces. - As discussed above, in an embodiment, if the local network device identifies an existing peering session with the peer network device through another link (e.g., link 112 b), the network device may forego making use of a full DTLS session for performing peer authentication for the link at issue and may instead use a simple challenge-response based authentication approach.
- When a timeout occurs, the link at issue is down, and/or the peer network device fails the challenge-response based authentication for the link at issue, the link state may transition back to the
unauthenticated state 402 and the peer network device may be periodically re-challenged. - Responsive to successful authentication of the peer network device by the local network device, the link state transitions to an authenticated
state 406. In an embodiment, the peers are periodically rekeyed and the link states remains in the authenticatedstate 406. In one embodiment, after at least one link state of a set of direct links between the local network device and the peer network device is in the authenticatedstate 406, each subsequent link between the local network device and the peer network device can be added via the challenge-response based authentication approach. - In the context of the present example, the link state transitions from the authenticated
state 406 back to theunauthenticated state 402 after the expiration of a preconfigured timeout period and/or when the link goes down. -
FIG. 5 is a block diagram 500 illustrating device discovery in accordance with an embodiment of the present disclosure. In the context of the present example, LLDP is enabled appropriate interfaces/ports of network devices 502 a-d to facilitate discovery of each other and collection of device information. Non-limiting examples of device information include a hostname, an address (e.g., an Media Access Control (MAC) address), a serial number and one or more capabilities (e.g., supported system capabilities (the primary function of the device, for example, a bridge, WLAN AP, or router), enabled system capabilities, port speed capabilities, aggregation capability, etc.) of a network device. - Network devices 502 a-b send LLDP advertisements to each other advertising their respective device information via each of their respective LLDP-enabled interfaces and the recipient network devices store the received device information in respective management information base (MIB) databases (e.g., internal MIB 506). While only one
internal MIB 506 is shown it is to be appreciated that each network device 502 a-d may have an associated internal MIB. In an embodiment, theinternal MIB 506 may include a local system MIB (not shown) and a remote system MIB (not shown). The local system MIB may store device information for the local device (the device's own information) and the remote system MIB may store device information gathered via LLDP advertisements received from the peer network devices. Responsive to discovering a peer network device on a particular link a network device may authenticate the peer network device using the authentication mechanism suggested below. - The various modules described herein (e.g.,
modules FIG. 6 may be implemented in the form of executable instructions stored on a machine readable medium and executed by a processing resource (e.g., a microcontroller, a microprocessor, central processing unit core(s), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), and the like) and/or in the form of other types of electronic circuitry. For example, the processing may be performed by one or more virtual or physical computer systems of various forms, such as the computer system described with reference toFIG. 7 below. -
FIG. 6 is a flow diagram illustrating secure link aggregation processing in accordance with an embodiment of the present disclosure. Atblock 602, a processing resource of a network device (e.g.,network device 104 c) within a secure domain discovers device information associated with a peer network device (e.g., peer network device 108) in an untrusted domain. According to one embodiment, this discovery process involves receipt of alayer 2 neighbor discovery protocol message (e.g., an LLDP advertisement) from the peer network device on a first link (e.g., link 112 a) directly coupling a first interface of the network device with a first interface of the peer network device. Thelayer 2 neighbor discover protocol may include device information (e.g., a host name, an address, and a serial number) of the peer network device. The device information may be stored within a local MIB (e.g., internal MIB 506) associated with the network device. - At
block 604, the processing resource authenticates the peer network device while allowing at least some network traffic to continue to be transmitted through the first interface. Depending upon the particular implementation, one or more authentication approaches may be used individually or in combination. A first peer authentication approach may involve the use of a DTLS session in which the network device confirms the peer network device has a properly signed certificate from a trusted CA (e.g., CA 110). A second peer authentication approach may involve a simple challenge-reply based authentication approach to confirm the peer network device has a valid key pair from the trusted CA, which may be confirmed by sending a set of data to be signed by the peer network device. In one embodiment, the first peer authentication approach is used when no validated peering sessions exist between the network device and the peer network device for any direct links therebetween and the second peer authentication approach is used, when a validated peering session already exists between the peers for at least one link. In an alternative embodiment, the first peer authentication approach may be used regardless of the existence of a validated peering session. In yet another alternative embodiment, the second peer authentication approach may be used regardless of the existence of a validated peering session. - At
block 606, the processing resource establishes a secure session between the network device and the peer network device over the first link. According to one embodiment, LACP begins to encrypt and decrypt all LACP packets on the authenticated link. Information regarding the authenticated session (also referred to herein as the validating peering session) may be stored in a database maintained by the network device. For example, a single DTLS session may be maintained per peer and keyed by the LLDP peer's serial number. According to another embodiment, encryption may be selectively performed based on one or more criteria (e.g., a type of packet, a protocol associated with the packet, etc.). - At
block 608, the processing resource allows the first link to operate as part of a single aggregated logical link (e.g., LAG 112) including a second link (e.g., link 112 b) coupling a second interface of the network device to a second interface of the peer network device. According to one embodiment, the network device marks the first link as an active member of the LAG. - In this manner, once the LAG is created, network traffic, including data packets and control packets, can be selectively transmitted in encrypted form using a negotiated encryption mechanism between the network device and peer network device. In scenarios, for example, in which full wire encryption is not feasible, particular types of packets (e.g., control traffic (STP, LACP, OSPF, etc.) vs. user traffic) may be selectively encrypted. Additionally, the approach described herein can be extended to protect other legacy protocols that do not natively support encryption.
- Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to example embodiments described herein with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various example embodiments described herein may involve one or more computing elements or computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of various example embodiments described herein may be accomplished by modules, routines, subroutines, or subparts of a computer program product.
-
FIG. 7 illustrates an exemplary computer system in which or with which embodiments of the present invention may be utilized. As shown inFIG. 7 , a computer system includes an external storage device 740, a bus 730, amain memory 715, a read-only memory 720, amass storage device 725, acommunication port 710, and one or more processing resources (e.g., processing circuitry 705).Computer system 700 may represent some portion of a network device (e.g.,network device - Those skilled in the art will appreciate that
computer system 700 may include more than one processor andcommunication ports 710. Examples ofprocessing circuitry 705 include, but are not limited to, an Intel® Itanium® orItanium 2 processor(s), or AMD® Opteron® or Athlon MP® processor(s), Motorola® lines of processors, FortiSOC™ system on chip processors or other future processors.Processing circuitry 705 may include various modules associated with embodiments of the present invention. -
Communication port 710 can be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports.Communication port 710 may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects. -
Memory 715 can be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-Only Memory 720 can be any static storage device(s) e.g., but not limited to, a Programmable Read-Only Memory (PROM) chips for storing static information e.g. start-up or BIOS instructions for processingcircuitry 705. -
Mass storage 725 may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), e.g. those available from Seagate (e.g., the Seagate Barracuda 7200 family) or Hitachi (e.g., the Hitachi Deskstar 7K1000), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks (e.g., SATA arrays), available from various vendors including Dot Hill Systems Corp., LaCie, Nexsan Technologies, Inc. and Enhance Technology, Inc. - Bus 730 communicatively
couples processing circuitry 705 with the other memory, storage, and communication blocks. Bus 730 can be, e.g. a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), USB or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connectsprocessing circuitry 705 to a software system. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure. - While embodiments of the present invention have been illustrated and described, it will be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents, will be apparent to those skilled in the art without departing from the spirit and scope of the invention, as described in the claims.
- Thus, it will be appreciated by those of ordinary skill in the art that the diagrams, schematics, illustrations, and the like represent conceptual views or processes illustrating systems and methods embodying this invention. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing associated software. Their respective functions may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic. Those of ordinary skill in the art further understand that the exemplary hardware, software, processes, methods, and/or operating systems described herein are for illustrative purposes and, thus, are not intended to be limited to any explicitly called out herein.
- It should be apparent to those skilled in the art that many more modifications besides those already described are possible without departing from the inventive concepts herein. The inventive subject matter, therefore, is not to be restricted except in the spirit of the appended claims. Moreover, in interpreting both the specification and the claims, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms “comprises” and “comprising” should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced. Where the specification claims refer to at least one of something selected from the group consisting of A, B, C . . . and N, the text should be interpreted as requiring only one element from the group, not A plus N, or B plus N, etc.
- While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.
Claims (20)
1. A method comprising:
discovering, by a processing resource of a network device within a secure domain, device information associated with a peer network device in an untrusted domain, wherein an interface of the network device is directly connected to an interface of the peer network device;
while allowing at least some network traffic to be transmitted through the interface of the network device, authenticating, by the processing resource, the peer network device; and
when the peer network device is successfully authenticated, establishing, by the processing resource, a secure session between the network device and the peer network device over a first link coupling the interface of the network device to the interface of the peer network device.
2. The method of claim 1 , wherein the interface is a first interface, the method further comprising:
allowing, by the processing resource, the first link to operate as part of a single aggregated logical link including a second link coupling a second interface of the network device to a second interface of the peer network device.
3. The method of claim 1 , wherein the discovering is done via a layer 2 neighbor discovery protocol that comprises Link Layer Discovery Protocol (LLDP).
4. The method of claim 1 , wherein the device information includes a hostname of the peer network device, an address of the peer network device, or a capability of the peer network device.
5. The method of claim 1 , wherein said authenticating comprises:
establishing, by the processing resource, a Datagram Transport Layer Security (DTLS) connection between the network device and the peer network device via the first link;
receiving, by the processing resource, a signed certificate from the peer network device via the DTLS connection; and
confirming, by the processing resource, the signed certificate is from a trusted certificate authority.
6. The method of claim 1 , wherein said authenticating comprises:
determining whether the peer network device is known to the network device as a result of having a previously validated peering session with the network device via the second link.
7. The method of claim 6 , wherein information indicative of the previously validated peering session is maintained within a database of the network device.
8. The method of claim 1 , wherein said authenticating comprises subjecting the peer network device to a challenge-response authentication mechanism.
9. The method of claim 1 , further comprising selectively encrypting, by the processing resource, packets transmitted on the single aggregated logical link.
10. A network device comprising:
a processing resource; and
a non-transitory computer-readable medium, coupled to the processing resource, having stored therein instructions that when executed by the processing resource cause the processing resource to:
discover via a layer 2 neighbor discovery protocol device information associated with a peer network device in an untrusted domain, wherein a first interface of the network device is directly connected to a first interface of the peer network device;
while allowing at least some network traffic to continue to be transmitted through the first interface, authenticate the peer network device; and
when the peer network device is successfully authenticated, establish a secure session between the network device and the peer network device over a first link coupling the first interface of the network device to the first interface of the peer network device.
11. The network device of claim 10 , allow the first link to operate as part of a single aggregated logical link including a second link coupling a second interface of the network device to a second interface of the peer network device.
12. The network device of claim 10 , wherein the layer 2 neighbor discovery protocol comprises Link Layer Discovery Protocol (LLDP).
13. The network device of claim 10 , wherein the device information includes a hostname of the peer network device, an address of the peer network device, or a capability of the peer network device.
14. The network device of claim 10 , wherein the peer network device is authenticated by:
establishing a Datagram Transport Layer Security (DTLS) connection between the network device and the peer network device via the first link;
receiving a signed certificate from the peer network device via the DTLS connection; and
confirming the signed certificate is from a trusted certificate authority.
15. The network device of claim 10 , wherein the peer network device is authenticated by determining whether the peer network device is known to the network device as a result of having a previously validated peering session with the network device via the second link.
16. The network device of claim 15 , wherein information indicative of the previously validated peering session is maintained within a database of the network device.
17. The network device of claim 10 , wherein the peer network device is authenticated by subjecting the peer network device to a challenge-response authentication mechanism.
18. The network device of claim 10 , wherein the instructions further cause the processing resource to selectively encrypt packets transmitted on the single aggregated logical link.
19. The network device of claim 18 , wherein selective encryption of the packets involves encrypting control traffic and not encrypting user traffic.
20. A non-transitory computer-readable medium having stored therein instructions that when executed by a processing resource cause the processing resource to:
discover via a layer 2 neighbor discovery protocol device information associated with a peer network device in an untrusted domain, wherein a first interface of the network device is directly connected to a first interface of the peer network device;
while allowing at least some network traffic to continue to be transmitted through the first interface, authenticate the peer network device;
when the peer network device is successfully authenticated, establish a secure session between the network device and the peer network device over a first link coupling the first interface of the network device to the first interface of the peer network device; and
allow the first link to operate as part of a single aggregated logical link including a second link coupling a second interface of the network device to a second interface of the peer network device.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/074,203 US20230099263A1 (en) | 2020-09-30 | 2022-12-02 | Secure link aggregation |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/039,853 US11533617B2 (en) | 2020-09-30 | 2020-09-30 | Secure link aggregation |
US18/074,203 US20230099263A1 (en) | 2020-09-30 | 2022-12-02 | Secure link aggregation |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/039,853 Continuation US11533617B2 (en) | 2020-09-30 | 2020-09-30 | Secure link aggregation |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230099263A1 true US20230099263A1 (en) | 2023-03-30 |
Family
ID=80821991
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/039,853 Active 2041-06-18 US11533617B2 (en) | 2020-09-30 | 2020-09-30 | Secure link aggregation |
US18/074,203 Pending US20230099263A1 (en) | 2020-09-30 | 2022-12-02 | Secure link aggregation |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/039,853 Active 2041-06-18 US11533617B2 (en) | 2020-09-30 | 2020-09-30 | Secure link aggregation |
Country Status (1)
Country | Link |
---|---|
US (2) | US11533617B2 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11533617B2 (en) * | 2020-09-30 | 2022-12-20 | Fortinet, Inc. | Secure link aggregation |
Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130318343A1 (en) * | 2012-05-22 | 2013-11-28 | Cisco Technology, Inc. | System and method for enabling unconfigured devices to join an autonomic network in a secure manner |
CN104243319A (en) * | 2013-06-06 | 2014-12-24 | 杭州华三通信技术有限公司 | Neighbor discovering method and device thereof |
WO2016081837A1 (en) * | 2014-11-21 | 2016-05-26 | Interdigital Patent Holdings, Inc. | Using security posture information to determine access to services |
US9432255B1 (en) * | 2014-01-15 | 2016-08-30 | Google Inc. | Systems and methods for controlling network device temporarily absent from control panel |
US20160254956A1 (en) * | 2015-02-26 | 2016-09-01 | Cisco Technology, Inc. | System and method for automatically detecting and configuring server uplink network interface |
US20160294632A1 (en) * | 2015-04-02 | 2016-10-06 | FixStream Networks, Inc. | Using spanning tree protocol to determine a layer 2 topology of an ethernet type network |
US20160330080A1 (en) * | 2015-05-08 | 2016-11-10 | Siddharth Bhatia | Method of discovering network topology |
WO2017010925A1 (en) * | 2015-07-15 | 2017-01-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Enabling setting up a secure peer-to-peer connection |
US20180189005A1 (en) * | 2016-12-30 | 2018-07-05 | Konica Minolta Laboratory U.S.A., Inc. | METHOD AND SYSTEM OF USING OAuth2 TO SECURE NEIGHBOR DISCOVERY |
US20190182119A1 (en) * | 2017-12-08 | 2019-06-13 | Apstra, Inc. | Intent-based analytics |
US20190190811A1 (en) * | 2017-12-14 | 2019-06-20 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Automatic sharing of routing information between neighboring routers using a link-local address |
US10333922B1 (en) * | 2013-08-13 | 2019-06-25 | Amazon Technologies, Inc. | Techniques for network site validation |
US20190230026A1 (en) * | 2018-01-19 | 2019-07-25 | Super Micro Computer, Inc. | Automatic multi-chassis link aggregation configuration with link layer discovery |
WO2020176021A1 (en) * | 2019-02-28 | 2020-09-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Automatic distribution of dynamic host configuration protocol (dhcp) keys via link layer discovery protocol (lldp) |
US20200313972A1 (en) * | 2019-03-26 | 2020-10-01 | Nokia Solutions And Networks Oy | Automatic discovery of ip-optical links with multi-layer filtering and traffic mapping using neural networks |
US20200358764A1 (en) * | 2019-05-07 | 2020-11-12 | Verizon Patent And Licensing Inc. | System and method for generating symmetric key to implement media access control security check |
US20210075716A1 (en) * | 2019-09-06 | 2021-03-11 | Arista Networks, Inc. | Automatic routing configuration between hosts and network layer devices |
US10992543B1 (en) * | 2019-03-21 | 2021-04-27 | Apstra, Inc. | Automatically generating an intent-based network model of an existing computer network |
US20210176255A1 (en) * | 2019-12-10 | 2021-06-10 | Cisco Technology, Inc. | Systems and methods for providing attestation of data integrity |
US20210184936A1 (en) * | 2019-12-11 | 2021-06-17 | Oracle International Corporation | System and method for modelling cloud networks for automation |
US20210352013A1 (en) * | 2020-05-11 | 2021-11-11 | Arista Networks, Inc. | Centralized Management and Distributed Enforcement of Policies for Network Segmentation |
US20220104016A1 (en) * | 2020-09-30 | 2022-03-31 | Fortinet, Inc. | Secure link aggregation |
-
2020
- 2020-09-30 US US17/039,853 patent/US11533617B2/en active Active
-
2022
- 2022-12-02 US US18/074,203 patent/US20230099263A1/en active Pending
Patent Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130318343A1 (en) * | 2012-05-22 | 2013-11-28 | Cisco Technology, Inc. | System and method for enabling unconfigured devices to join an autonomic network in a secure manner |
CN104243319A (en) * | 2013-06-06 | 2014-12-24 | 杭州华三通信技术有限公司 | Neighbor discovering method and device thereof |
US10333922B1 (en) * | 2013-08-13 | 2019-06-25 | Amazon Technologies, Inc. | Techniques for network site validation |
US9432255B1 (en) * | 2014-01-15 | 2016-08-30 | Google Inc. | Systems and methods for controlling network device temporarily absent from control panel |
WO2016081837A1 (en) * | 2014-11-21 | 2016-05-26 | Interdigital Patent Holdings, Inc. | Using security posture information to determine access to services |
US20160254956A1 (en) * | 2015-02-26 | 2016-09-01 | Cisco Technology, Inc. | System and method for automatically detecting and configuring server uplink network interface |
US20160294632A1 (en) * | 2015-04-02 | 2016-10-06 | FixStream Networks, Inc. | Using spanning tree protocol to determine a layer 2 topology of an ethernet type network |
US20160330080A1 (en) * | 2015-05-08 | 2016-11-10 | Siddharth Bhatia | Method of discovering network topology |
WO2017010925A1 (en) * | 2015-07-15 | 2017-01-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Enabling setting up a secure peer-to-peer connection |
US20180189005A1 (en) * | 2016-12-30 | 2018-07-05 | Konica Minolta Laboratory U.S.A., Inc. | METHOD AND SYSTEM OF USING OAuth2 TO SECURE NEIGHBOR DISCOVERY |
US20190182119A1 (en) * | 2017-12-08 | 2019-06-13 | Apstra, Inc. | Intent-based analytics |
US20190190811A1 (en) * | 2017-12-14 | 2019-06-20 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Automatic sharing of routing information between neighboring routers using a link-local address |
US20190230026A1 (en) * | 2018-01-19 | 2019-07-25 | Super Micro Computer, Inc. | Automatic multi-chassis link aggregation configuration with link layer discovery |
WO2020176021A1 (en) * | 2019-02-28 | 2020-09-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Automatic distribution of dynamic host configuration protocol (dhcp) keys via link layer discovery protocol (lldp) |
US10992543B1 (en) * | 2019-03-21 | 2021-04-27 | Apstra, Inc. | Automatically generating an intent-based network model of an existing computer network |
US20200313972A1 (en) * | 2019-03-26 | 2020-10-01 | Nokia Solutions And Networks Oy | Automatic discovery of ip-optical links with multi-layer filtering and traffic mapping using neural networks |
US20200358764A1 (en) * | 2019-05-07 | 2020-11-12 | Verizon Patent And Licensing Inc. | System and method for generating symmetric key to implement media access control security check |
US20210075716A1 (en) * | 2019-09-06 | 2021-03-11 | Arista Networks, Inc. | Automatic routing configuration between hosts and network layer devices |
US20210176255A1 (en) * | 2019-12-10 | 2021-06-10 | Cisco Technology, Inc. | Systems and methods for providing attestation of data integrity |
US20210184936A1 (en) * | 2019-12-11 | 2021-06-17 | Oracle International Corporation | System and method for modelling cloud networks for automation |
US20210352013A1 (en) * | 2020-05-11 | 2021-11-11 | Arista Networks, Inc. | Centralized Management and Distributed Enforcement of Policies for Network Segmentation |
US20220104016A1 (en) * | 2020-09-30 | 2022-03-31 | Fortinet, Inc. | Secure link aggregation |
US11533617B2 (en) * | 2020-09-30 | 2022-12-20 | Fortinet, Inc. | Secure link aggregation |
Also Published As
Publication number | Publication date |
---|---|
US20220104016A1 (en) | 2022-03-31 |
US11533617B2 (en) | 2022-12-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9735957B2 (en) | Group key management and authentication schemes for mesh networks | |
US8037514B2 (en) | Method and apparatus for securely disseminating security server contact information in a network | |
EP2055071B1 (en) | Improved authentication for devices located in cable networks | |
US8886934B2 (en) | Authorizing physical access-links for secure network connections | |
US7529933B2 (en) | TLS tunneling | |
JP3844762B2 (en) | Authentication method and authentication apparatus in EPON | |
US7710903B2 (en) | System and method for floating port configuration | |
US8312263B2 (en) | System and method for installing trust anchors in an endpoint | |
US11451959B2 (en) | Authenticating client devices in a wireless communication network with client-specific pre-shared keys | |
CN1319337C (en) | Authentication method based on Ethernet authentication system | |
CN103368905A (en) | Trustable cipher module chip-based network access authentication method | |
US20230099263A1 (en) | Secure link aggregation | |
US11552994B2 (en) | Methods and nodes for handling LLDP messages in a communication network | |
CN102271120A (en) | Trusted network access authentication method capable of enhancing security | |
CN103780389A (en) | Port based authentication method and network device | |
CN101272379A (en) | Improving method based on IEEE802.1x safety authentication protocol | |
US8031596B2 (en) | Router associated to a secure device | |
CN113973001A (en) | Method and device for updating authentication key | |
JP4568857B2 (en) | Authentication transmission system | |
CN115348112B (en) | Method for local area network exchange equipment access authentication and trusted networking | |
US11973700B2 (en) | Trusted remote management unit | |
CN115314278B (en) | Trusted network connection identity authentication method, electronic equipment and storage medium | |
US20220078138A1 (en) | Trusted remote management unit | |
KR20240003977A (en) | Method for verifying integrity of application in vehicle controller | |
Bicakci et al. | Pushing the limits of address based authentication: how to avoid MAC address spoofing in wireless LANs |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: FORTINET, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MIHELICH, JOSEPH R.;XU, XIAO;SRIVASTAV, AMIT;AND OTHERS;SIGNING DATES FROM 20201019 TO 20210301;REEL/FRAME:061960/0557 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: SENT TO CLASSIFICATION CONTRACTOR |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |