Patent Description:
LLDP is e.g. used to provide unidirectional, unauthenticated and unsecured topology discovery in the Ethernet layer, see IEEE <NUM>. 1AB e.g. draft <NUM>. Today, LLDP over Ethernet networks are often used during fault management for topology discovery and validation. Received LLDP information is not verified by any security mechanism of the network elements receiving it. However, sometimes it is motivated to secure LLDP communication. For example, in Software Defined Networks (SDNs), LLDP may be a primary source behind the SDN physical topology database that is used by several applications. Many SDN applications are based on such topology discovery of network infrastructure. The primary information source of the physical layer connectivity of an SDN topology database is gathered from LLDP messages, typically by some kind of management node, e.g. SDN controller (SDNc). Validation and verification by security mechanisms is therefore desirable or even essential in some situations, e.g. in order to accomplish a topology information database that can be trusted.

There are two currently available solutions at the Ethernet layer to provide security: (i) the MACSec (<NUM>. 1AE approved June <NUM>th <NUM>) protocol that provides data confidentiality and integrity and (ii) the Port Based Authentication (<NUM>. 1X e.g. published as <NUM>. 1X-<NUM>) protocol that provides an authentication mechanism to connected devices. These protocols work on a per port level, so they are applied to all traffic crossing that port.

<NPL>, investigates the vulnerability of link discovery service in SDN controller, including discussions on potential attacks and experimental verifications. It also discusses countermeasures to prevent attacks.

<NPL>, proposes a solution for continuous measurements of the integrity of Smart Meter Gateways and connected Smart Meters in order to protect smart grid components against IT based attacks. A protocol developed for the purpose of establishing a required level of trust is presented as a variant of the Link-Layer Discovery Protocol (LLDP).

In view of the situation indicated above, an object is to provide one or more improvements regarding how network nodes in a communication network can be managed based on Link Layer Discovery Protocol (LLDP) messages.

According to a first aspect of embodiments herein, the object is achieved by a method, as defined in claim <NUM>, performed by a management node, for supporting management of network nodes comprised in a communication network. The management node receives, from at least some of said network nodes, LLDP information. The LLDP information is information obtained by said nodes based on one or more LLDP messages received from neighboring network nodes that are neighbouring said at least some network nodes. The LLDP information comprises security status information regarding said neigbouring network nodes. The security status information regarding a neighbouring network node indicates if the neighbouring network node has been verified to be authentic and indicates if the neighbouring network node has been verified to be not authentic.

According to a second aspect of embodiments herein, the object is achieved by a computer, as defined in claim <NUM>, comprising instructions that when executed by a processing circuit causes the management node to perform the method according to the first aspect.

According to a third aspect of embodiments herein, the object is achieved by a carrier, as defined in claim <NUM>, comprising the computer program according to the second aspect, wherein the carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

According to a fourth aspect of embodiments herein, the object is achieved by a management node, as defined in claim <NUM>, for supporting management of network nodes comprised in a communication network. The management node is configured to receive, from at least some of said network nodes, LLDP information. The LLDP information is information obtained by said nodes based on one or more LLDP messages received from neighboring network nodes that are neighbouring said at least some network nodes.

The LLDP information comprises security status information regarding said neigbouring network nodes. The security status information regarding a neighbouring network node indicates if the neighbouring network node has been verified to be authentic and indicates if the neighbouring network node has been verified to be not authentic.

The security status information received with LLDP information, e.g. in MIBs, from the network nodes thus indicates which neighbouring network nodes to said network nodes that have been verified to be authentic and/or which that have been verified to be not authentic. This enables the management node to take into account whether network nodes, e.g. discovered via a discovery procedure based on LLDP messages, are authenticated and/or which are not. This in turn provides improved security in the communication network and an improvement regarding how network nodes can be managed based on LLDP messages in the communication network. Conventionally, management based on LLDP messages are based on MIBs compiled based on information from LLDP messages, but there is no security status information involved as in embodiments herein.

Embodiments herein are advantageously used together with certain other solutions disclosed herein that are based on security related information in the LLDP messages, which security related information enables to verify the authenticity of the node transmitting the LLDP message.

Examples of embodiments herein are described in more detail with reference to the appended schematic drawings, which are briefly described in the following.

As part of the development towards embodiments herein, the situation indicated in the Background will first be further elaborated upon.

While the existing "per port" protocols mentioned in the Background can be used to accomplish desired security regarding e.g. authentication and message integrity, they will in some situations result in undesired side effects, e.g. unnecessary processing and overhead and thereby unnecessary energy consumption and/or reduced performance. Reduced performance is here both regarding additional computation needed and additional delay caused by the additional computation. Such situation may e.g. occur when the communication network is part of a Radio Access Network (RAN) that in turn may be comprised in a New Radio (NR), also referred to as <NUM>, wireless communication network, designed to be based on Software Defined Networking (SDN) and to be energy and performance efficient. In such network there is also already encryption provided by higher layers and therefore encryption per port on lower layers result in partly unnecessary security being added to the cost of reduced performance and/or increased energy consumption.

More specifically, LLDP is lacking any security mechanism so without any deep technology knowledge an MiTM (Man in The Middle) attacker or an end-point device may:.

Further, LLDP is a relatively slow protocol with a limited size of Management Information Database (MIB) database/storage and a MIB can be overutilized from a single client with forged messages.

A purpose with LLDP security may therefore to be able to authenticate neighbour node(s) and/or check the integrity of LLDP messages and/or provide encryption of LLDP messages/content.

MACSec as mentioned in the Background encrypts all traffic on a port and requires hardware support to ensure line-rate encryption. 1X provides port base authentication, which is affecting the whole port operation. It requires maintaining an authentication architecture, e.g. a Remote Authentication Dial In User Service (RADIUS) server, certificate allocation systems, etc..

As already mentioned, LLDP is a "slow protocol" where bandwidth required is minimal and the frame transmission rate is limited to a maximum of <NUM> frames per second. Therefore, using MACSec / <NUM> X is overkill just for the purpose of LLDP security and would impact all other traffic sent over a given port.

Further, the existing LLDP protocol sends the messages in unencrypted format, i.e. in cleartext.

Based on the above it has been identified a need when LLDP messages are used to provide improvements regarding security, e.g. node authentication and/or message integrity, and also to provide improvements regarding how network nodes in a communication network can be managed based on LLDP messages.

<FIG> schematically depicts an example of a communication network <NUM> in which embodiments herein may be implemented. Features that may be present in only some embodiments are typically drawn with dotted lines. The communication network <NUM> may e.g. be or comprise a RAN and/or be part of a NR or <NUM> wireless communication network. Another example of the communication network <NUM> is a network that is part of and/or controlled by a data center. The communication network <NUM> typically comprises a transport network or Ethernet network. The communication network <NUM> further comprises one or more network nodes that are transmitting and/or receiving nodes <NUM>-<NUM>. These nodes may be directly or indirectly interconnected. Note that while some network nodes <NUM>-<NUM> in the following may be named only transmitting node or receiving node, this naming has typically been selected just for exemplifying purposes, e.g. for facilitating understanding of an example where transmitting capabilities of the network node is in focus. However, in practise a network node that is named a transmitting node typically also has receiving capabilities, and vice versa. For example, an Ethernet switch, being a transmitting node, e.g. the transmitting node <NUM>, may at the same time also be a receiving node regarding other messages transmitted to the transmitting node <NUM>, e.g. from another network node, e.g. from the network node <NUM>.

The transmitting and/or receiving nodes <NUM>-<NUM> may e.g. be physical or virtual nodes, where the latter e.g. may be the case when the communication network <NUM> is associated with a data center.

Each of the transmitting and/or receiving nodes <NUM>-<NUM> has one or more neighbours, i.e. neighbouring nodes they are directly connected to. Neighbouring nodes, such as the transmitting node <NUM> and the receiving node <NUM>, may communicate directly with each other without doing so via one or more intermediate nodes.

The transmitting and/or receiving nodes <NUM>-<NUM> may, as shown in the figure, belong to different network domains, e.g. the transmitting and/or receiving nodes <NUM>-<NUM> may be comprised in a first network domain 101a while the transmitting and/or receiving nodes <NUM>-<NUM> may be comprised in a second network domain 101b. Networks domains may distinguish from each other by some network separation and/or isolation, and e.g. correspond to different subnetworks. They may differ in purpose, management, control and/or administration, e.g. there may be different administration entities involved. Different network domains may e.g. be administrated by different organization. Typically, different network domains also means different security domains. One network domain, e.g. <NUM> a may contain radio nodes, e.g. of a RAN, and another network domain, e.g. 101b may contain transport nodes and/or e.g. be part of a core network.

Further, the communication network <NUM> may comprise one or more management nodes, e.g. a first management node <NUM> and a second management node <NUM>, e.g. SDN management or SDC controller (SDNc) nodes. The first management node <NUM> may e.g. be associated with the first network domain 101a and be communicatively connected to nodes thereof, e.g. the transmitting and/or receiving nodes <NUM>-<NUM>. The second management node <NUM> may e.g. be associated with the second network domain 101b and be communicatively connected to nodes thereof, e.g. the transmitting and/or receiving nodes <NUM>-<NUM>. The one or more management nodes may e.g. maintain one or more topology databases, e.g. one each, based on information received from the transmitting and/or receiving nodes <NUM>-<NUM>.

Moreover, the communication network <NUM> may comprise a security administrating node <NUM> that e.g. can be associated with to an authority and/or correspond to a server, such as a Certificate Authority (CA) server. Note that the security administrating node <NUM> alternatively may be located remotely, e.g. outside the communication network <NUM>, but be communicatively connected to the communication network <NUM> and nodes thereof. The security administrating node <NUM> is in the figure indicated by dotted arrows to be communicatively connected to only three nodes just not to obscure the figure too much, however, the security administrating node <NUM> may be communicatively connected to and thereby accessible by all the nodes.

Attention is drawn to that <FIG> is only schematic and for exemplifying purpose and that not everything shown in the figure may be required for all embodiments herein, as should be evident to the skilled person. Also, a communication network that corresponds to the communication network <NUM> will in practise typically comprise several further network nodes, as realized by the skilled person, but which are not shown herein for the sake of simplifying.

<FIG> depicts a first combined signalling diagram and flowchart, which will be used to exemplify and discuss some examples herein. Two transmitting nodes <NUM> and <NUM> and a receiving node <NUM> have been selected as examples of the transmitting and/or receiving nodes <NUM>-<NUM>.

The actions below may be taken in any suitable order and/or be carried out fully or partly overlapping in time when this is possible and suitable.

One or more of the transmitting and/or receiving nodes <NUM>, <NUM>, <NUM> may be (pre-)configured and/or (pre-)installed) with a security configuration e.g. comprising certain security settings and/or data. This may be done before or at installation of the respective node in the communication network <NUM> and/or at some later point in time and it may be performed at least partly manually and/or by means of some secure access to the nodes. Said configuration for a node, e.g. the transmitting node <NUM> or the receiving node <NUM>, may be regarding to the whole node or for one or more communication ports thereof, i.e. may per on a per port level instead of for the whole node. If it is for the whole node, i.e. per node basis, the same applies for all relevant communication ports thereof. Hence, the configuration of a node may configure this node and/or communication ports thereof so it and/or the ports become able and/or is supported to handle security related information (see below) in LLDP messages and act as transmitting and/or receiving node according to examples herein. The security configuration for a node may e.g. comprise one or more of the following:.

Said one or more cryptography keys may comprise one or more of the following:.

The above-mentioned TLVs, security related information, security policies, encrypted content, keys and how they may be used with and relate to examples herein are explained below.

The transmitting node <NUM> and the transmitting node <NUM> may transmit LLDP messages, respectively, to a receiving node, here the receiving node <NUM>, of the communication network <NUM>. More particularly, as should be realized, the communication takes part between two communication ports of the involved nodes, respectively. The LLDP messages may be sent at different points in time. The LLDP messages sent in actions 201a-b comprise security related information enabling to verify authenticity of the transmitting node that transmitted it and/or integrity of the message. For example, the LLDP message transmitted in action 201a comprises security related information that, preferably by means of encryption, enables to verify authenticity of the transmitting node <NUM> and/or integrity of the message. The authenticity of the transmitting node <NUM> may be regarding the involved communication port, i.e. the communication port that transmitted the message. In other words, the authenticity of the transmitting node <NUM> may be at least regarding the communication port that transmitted the LLDP message.

In general, a receiving node, e.g. the receiving node <NUM>, or more particularly one or more communication ports thereof, may receive multiple LLDP messages from different nodes and/or ports, but not all may contain security related information. The receiving node <NUM> may thus receive one or more LLDP messages where at least one, e.g. as in action 201a and/or action 201b, contain security related information as disclosed herein.

The security related information may comprise encrypted information that enables to verify said authenticity.

Said encryption, by means of which the security related information may enable to verify said authenticity, may be accomplished, i.e. said encrypted information may be encrypted, by one or more of the following:.

Moreover, the encryption, by means of which the security related information may enable to verify said authenticity, i.e. said encrypted information, may relate to, and/or comprise, a cryptographically signed, and/or encrypted, identifier of the transmitting node <NUM>. The identifier may be regarding the transmitting node <NUM> as a whole and/or a communication port thereof that transmitted the LLDP message.

Further, the security related content may further comprises a cryptographically signed and/or encrypted integrity check value, e.g. a hash sum, regarding the LLDP message.

In other words, the encryption, by means of which the security related information may enables to verify the authenticity and/or the integrity of the LLDP message, may correspond to certain encrypted information comprised in the security related information and that may be encrypted by said one or more keys.

The LLDP message may be transmitted based on security status or similar stored by the transmitting node <NUM>, e.g. in its MIB, regarding the receiving node <NUM>. For example, the LLDP message comprising the security related information may be transmitted based on that the security status, e.g. the MIB, indicates that the receiving node <NUM>, e.g. the involved communication port thereof, supports security related information, else another conventional LLDP message may be transmitted instead.

By introducing the security related information in LLDP messages as in the present action and in examples herein, drawbacks as indicated above for prior art methods can be avoided while still node and/or communication port authentication and/or message integrity can be accomplished. More flexible and efficient security is provided where node and/or port authentication and message integrity can be accomplished with less impact on performance and energy consumption. For example, it can be avoided unnecessary processing and overhead resulting from using the prior art methods. Thereby unnecessary energy consumption and/or reduced performance can be avoided. Hence, e.g. LLDP topology discovery procedures relating to infrastructure of the communication network <NUM> are facilitated and can be accomplished securely and more efficiently than conventionally.

As understood from the above, the LLDP message(s) may advantageously be transmitted in association with a topology discovery procedure regarding the communication network <NUM>. The topology discovery procedure may relate to SDN infrastructure. Further, the topology discovery procedure may be initiated by receipt of the transmitted LLDP message by the receiving node <NUM> and/or may be initiated by a management node, e.g. the management node <NUM>, that may be manging, such as controlling, the topology discovery procedure.

The security related information of a LLDP message is advantageously comprised in one or more security related TLVs) which security related TLVs are certain TLVs of the LLDP message assigned to contain the security related information, and/or the transmitting node <NUM> and/or the receiving node <NUM> may be configured to use said TLVs for the security related information.

These TLVs may correspond to one or more of so called organizationally specific TLVs supported by conventional existing LLDP messages, which have been assigned to contain the security related information. An advantage with using such TLVs is thus that there is backwards compatibility and that implementation in existing systems is facilitated.

The following TLV categories are specified in the LLDP standard of today (see <NUM>. 1AB-<NUM>):.

In some examples, the LLDP message further comprises encrypted content, e.g. an encrypted content TLV. The encrypted content contains encrypted one or one or more TLVs being cleartext TLVs that have been encrypted. Further, the encrypted content TLV may be a TLV of the LLDP message assigned to contain encrypted content and/or that the transmitting node <NUM> and/or the receiving node is configured to use and/or process as containing encrypted content, i.e. encrypted data content. This way the LLDPs can be used to carry also encrypted content in a very flexible way that is compatible with existing functionality for handling LLDP messages. For example, a legacy or conventional node that receive a LLDP message with an encrypted content TLV may see it as a normal TLV with some content and can handle it accordingly. Only a node that supports encrypted content TLVs may identify it as such and may also have ability to decrypt the encrypted one or one or more TLVs contained in the encrypted content TLV.

Use of encrypted content may for security reasons be allowed, or be considered, only if the node and/or port transmitting the LLDP message first is verified to be authentic.

Any mandatory TLV, such as the mandatory TLVs mentioned above, part of the LLDP message, should of course be unencrypted, but any other TLV may be encrypted and e.g. part of an encrypted TLV set. During encryption, the transmitting node <NUM> may insert the encrypted TLV-set into a Encrypted-Content Container' TLV that corresponds to said encrypted content TLV. The receiving node <NUM> may then process the Encrypted-Content Container TLV as a set of embedded TLVs and after decryption process them as cleartext TLVs.

One or more cryptographic keys for encrypting/decrypting the encrypted content, e.g. one or one or more encrypted TLVs may be preconfigured such as in actions 200a-c, and/or may be provided by other means, e.g. result from actions on higher levels, e.g. by a management node, e.g. the first management node <NUM>, or by applications involved. However, it is also possible that e.g. a public key of a key pair associated with the receiving node may be used by the transmitting node <NUM> for encryption and a private key of the keypair may be used by the receiving node <NUM> for decryption. Hence, the encryption used for the encrypted content may be symmetric, e.g. using a pre-shared and/or pre-configured key or be asymmetric, e.g. using a public key.

When the encrypted content TLV has been decrypted, the result may thus be one or more TLVs that no longer are encrypted and thus again are in cleartext and thereby can be handled as TLVs conventionally are handled.

It is typically on a use-case or case by case basis which information may be sent by LLDP without security risk and which information that needs to be secure at some level, e.g. encrypted and/or only be communicated via authentic nodes and/or ports. Examples herein e.g. make it possible to send topology details in encrypted format without the risk of sharing confidential topology information with unauthorized peers.

The receiving node <NUM> may store, based on receipt of said at least one LLDP message comprising security related information, a verification status regarding the transmitting node, e.g. the transmitting node <NUM>, that transmitted this LLDP message. The verification status indicating if said verification of authenticity is not yet performed, e.g. that it cannot yet be verified or is not yet verified. The verification status may be temporarily stored.

Hence, there may be a verification status regarding the transmitting node <NUM> that indicates if the transmitting node <NUM> and/or transmitting port thereof cannot be or has not yet been verified although a LLDP message with security related information has been received from it. The verification status is preferably temporarily stored and not e.g. part of a MIB. There may be some delay, e.g. in case verification must involve one or more other nodes, e.g. the security administrating node <NUM>, until verification can be done or finalized based on a received LLDP message with security related information. Being able to set the verification status reflecting this makes it possible to continue and handle the node in question in a more efficient and still secure way until verification can and/or has been accomplished. The "not yet verified" may be a default verification status for all neighboring nodes of the receiving node <NUM> until a LLDP message with security related information has been received and/or verification (see below) of this LLDP message has been performed.

The receiving node <NUM> may, following actions <NUM> and/or <NUM>, based on the security related information of each received LLDP message, verify:.

For any LLDP message received without security related information, the receiving node <NUM> may skip the verification in the present action, or still attempt it. The result may be that verification fails or is considered to have failed regarding these messages and/or nodes and/or ports thereof.

The verification of authenticity may further be based on the first and/or said one or more third cryptographic keys mentioned in action 200a, i.e. typically a public cryptographic key of the security administrating node <NUM> or a public cryptographic key of the transmitting node <NUM>. The former may be used in case the encrypted information of the security related information, such as signed identifier of the transmitting node <NUM>, has been accomplished by a private cryptographic key of the security administrating node <NUM>. The latter may be used in case the encrypted information of the security related information, such as signed identifier of the transmitting node <NUM>, has been accomplished by a private cryptographic key of the transmitting node <NUM>.

In case the receiving node <NUM> is configured with the private cryptographic key of the transmitting node <NUM> in action 200a, it can be avoided to involve the security administrating node <NUM>, but this would typically require that the receiving node <NUM> in action 200a is configured in advance with, preferably all, relevant public keys of neighbouring nodes.

Further, the receiving node <NUM> may store, based on the verification in action <NUM>, security status regarding one or more transmitting nodes, e.g. regarding communication ports thereof, that it has received LLDP messages from. The security status is typically stored in an information record, such as a MIB, associated with and typically managed by the receiving node <NUM>. The stored security status may be accomplished by, e.g. an existing MIB table may be extended with, one or more status flags, such as an authentication flag, for example in a new field added to a conventional MIB.

The receiving node <NUM> may e.g. have received LLDP messages with security related information, respectively, from the transmitting nodes <NUM> and <NUM>, and it may also (not shown) have received one or more LLDP messages from other nodes but without security related information, e.g. because these nodes, and/or communication ports involved, do not support examples herein and/or or were configured not to transmit security related information as in examples herein.

The security status information regarding a transmitting node and/or communication port thereof, e.g. the transmitting node <NUM> or <NUM>, may indicate if the transmitting node, e.g. port thereof, has been verified to be authentic, and/or if the transmitting node, e.g. port thereof, has been verified to be not authentic. For example, for transmitting node <NUM> it may indicate that the node has been verified to be authentic while it for transmitting node <NUM> may indicate that the node has been verified to be not authentic. The security status information regarding a transmitting node and/or communication port thereof may also indicate whether or not the transmitting node and/or communication port supports security related content.

From the stored security status of the receiving node <NUM> or a communication port thereof, it may thus be possible to be informed about security status of nodes and/or communication ports that the receiving node <NUM> has received LLDP messages from, typically all its neighboring nodes, and if these nodes have passed authenticity verification or not, and/or if they support security related information. The security status of a transmitting node or communication port may be based on the latest received LLDP message from that transmitting node or communication port. The security status is typically stored, e.g. in a MIB; together with node and/or identifiers and/or cryptographic keys, e.g. public keys, associated with the nodes and/or ports, respectively. A public key may correspond to such an identifier, as already mentioned.

Any LLDP message that does not contain security related information may be associated with a security status corresponding to that the transmitting node, or communication port thereof, has not, at least not yet, been verified to be authentic.

In some examples, storing the security status is based on if the receiving node <NUM> that received the LLDP message is configured, e.g. in action 200a, to apply a certain first security policy instead of another, second security policy. Both security policies should be supported and/or be selectable for the receiving node <NUM>. The first security policy may thus be selectable by configuration and may be stricter than the second security policy. The first or second security policy may alternatively or additionally be a default and/or implicit security policy that applies if there is not any explicitly configured security policy.

As a result, a node and/or port that applies a certain security policy, e.g. the first security policy, may store information, such as security status and identifiers, e.g. in its MIB, only regarding nodes and/or ports that are verified as authentic. If on the other hand the receiving node <NUM> and/or port applies said second and e.g. a less strict security policy, it may be stored security status regarding both authenticated and unauthenticated nodes and/or ports.

An advantage of storing the security status in e.g. an information record such as a MIB, is that the information then can be used for managing further communication to and/or from the node in question, and it can also be used to report status of e.g. all neighboring nodes of the receiving node <NUM> to e.g. one or more managing or controlling nodes of the receiving node <NUM>, such as to the first management node <NUM>. Said one or more management nodes can then e.g. use the information for topology discovery and/or to take actions to (re)configure the nodes, such as improving security.

Further, the stored security status enables improved security and e.g. mitigate the risk of so called distributed Denial of Service (dDoS) attacks by clearing or removing 'unauthenticated' peers, i.e. nodes or ports, and related information from the table, or to enable actions regarding network planning in the communication network <NUM> so that unauthenticated nodes or ports can change and be verified as authentic.

The receiving node <NUM> may, based on said verification in action <NUM>, manage said one or more received LLDP messages, e.g. as received in actions 201a-b, whereby a received LLDP message is:.

As should be understood, further processed here means further used, e.g. that other content than the security related information is used by the receiving node and/or passed on to another node and/or layer. Using the information may result in updating of the information record, e.g. the MIB, also regarding other information than security status.

In some examples, the received LLDP message is managed also based on if the receiving node <NUM> that received the LLDP message is configured, e.g. in action 200a, to apply a certain first security policy instead of another, second security policy. These security policies may be the same as discussed above for action <NUM>.

The first security policy may thus be selectable by configuration and may be stricter than the second security policy. The security policy may also be selectable by configuration, or may be a default and/or implicit security policy that applies without any explicitly configured security policy.

The receiving node <NUM> may in this action, e.g. when the verification and/or settings result in that the received LLDP message shall be further processed, check whether information in the LLDP message is already known or if it is new, e.g. information about the transmitting node <NUM>. If the information is new the receiving node <NUM> may e.g. initiate communication towards the management node <NUM>, e.g. a SDN controller (SDNc), to inform it about the new information, e.g. new topology information. One way to accomplish this may be that the receiving node initiate communication towards the management node <NUM> so that the management node <NUM> gets informed about the information record, e.g. MIB, when there is a change in the information record, e.g. regarding security status of a node, which change may have been caused by a received LLDP message.

Another way the receiving node <NUM>, in practise any device, e.g. Ethernet switch, that implements the receiving node <NUM>, may utilize the security status (typically comprised in the MIB) regarding neighbouring nodes, is for making switching decisions, i.e. for deciding how data packets communicated in the communication network <NUM> shall be switched or routed. In other words, switching decisions may be based on the security status. This may be accomplished by a certain entity comprised in the receiving node <NUM>, such as a so called Spanning Tree Protocol entity in the receiving node <NUM>, e.g. when it is a switch. Such entity may factorize the state of security, e.g. based on the security status, regarding neighbouring nodes when loop-free switching paths are computed to various destinations and/or addresses, typically Media Access Control (MAC) addresses.

As should be recognized by the skilled person, by "verifying authenticity of a node" is herein meant the action of verifying whether the node or at least a communication port thereof is authentic or not. If it is not authentic it may be a malicious node and/or a node that is not authorized, not trustworthy and/or not allowed to be part of the communication network <NUM> and should therefore not be trusted and/or not used and/or be subject to some change actions, e.g. an update or replacement.

As should be recognized by the skilled person, by "verifying integrity of a message" is herein meant verifying whether or not the message is identical with the transmitted message, i.e. is the same message, or not. In other words, to verify if the message being subject to the verification is the message that was actually transmitted or if it is not. If the message is not the message that was actually transmitted it may have been replaced by a malicious message, e.g. as part of an attempt of unauthorized access in the communication network <NUM> and/or to cause harm.

As should be recognized by the skilled person, "security related information enabling to verify authenticity of the transmitting node and/or integrity of the message" may e.g. comprise an identity, i.e. node identifier or node id, and a (cryptographic) key of the transmitting node <NUM>, and an Integrity Check Value (ICV), typically a hash sum, regarding the message.

The identity and key may advantageously be combined, e.g. may be a node identifier of the transmitting node <NUM>, which node identifier may comprise or correspond to a cryptographic key of the transmitting node <NUM> and may be comprised in a so called certificate associated with and typically installed on the transmitting node <NUM>. The cryptographic key is advantageously a key as used in asymmetric encryption using a key pair, typically a public key and a private key. The private key is not to be distributed and instead e.g. kept on the node that generated the key pair, i.e. the private key corresponds to a secret key. The public key is instead for use outside the node that generated the key pair. Information that have been encrypted using one of the keys of the key pair can typically only be decrypted using the other key of the key pair, and vice versa. The encryption is advantageously based on a so called Public Key Infrastructure (PKI), i.e. based on asymmetrical encryption algorithms, although symmetric algorithms using shared keys also may be used. The nodes applying examples herein may thus have a private-public key pairs, respectively, e.g. generated by any asymmetric algorithm as defined by Federal Information Processing Standards (FIPS) <NUM> Version <NUM>. The nodes applying examples herein may further be associated with certificates, respectively, each certificate comprising a public key and a node identifier of the associated node and which typically are the same.

The node identifier, typically comprised in a certificate, is advantageously signed e.g. by a trusted source, such as the security administrating node <NUM> that, as mentioned above, may correspond to an authority and/or server, e.g. a Certificate Authority (CA) that have issued said certificate.

The skilled person should understand that a piece of information, e.g. an identifier, being "signed" in the context of the present application typically refers to encoding, or encrypting, information associated with or corresponding to this piece of information, e.g. using an encryption key of a sender and/or originator of the piece of information, so that a receiver of the piece of information can decode or decrypt the information and thereby verify that the piece of information actually was sent from and/or originated from said sender and/or originator. Typically, this is accomplished by signing, i.e. encoding or encrypting, using the private key of a key pair, and decoding or decrypting using the public key of the key pair.

For example, the node identifier of the transmitting node <NUM>, e.g. being comprised in the certificate, may be signed by a private key of the trusted source, e.g. security administrating node <NUM> that may have issued the certificate that the node identifier is part of. However, in some examples, the node identifier of the transmitting node <NUM> may be signed by a private key of the transmitting node <NUM>. The latter is advantageous in that it does not require involvement of another, e.g. external, node such as the security administrating node <NUM>, but may instead require that the corresponding public key of the transmitting node is available to the receiving node, e.g. that the receiving node has been configured with it previously. It may also require that the involved nodes, e.g. the transmitting node <NUM> and the receiving node <NUM>, are in the same network domain, e.g. in the network domain 101a, and that this domain is considered sufficiently secure and/or controlled. If the involved nodes are in different network domains, e.g. when they are border nodes, e.g. as in the case of nodes <NUM> and <NUM> in <FIG>, then the security administrating node <NUM> or similar may need to be involved.

The integrity check value is preferably a hash sum resulting from hashing the LLDP message (preferably the whole message both a mandatory and any optional part) with a hash algorithm, e.g. FIPS140 version <NUM>. The integrity check value is advantageously signed, e.g. encoded or encrypted, by the private key of the transmitting node <NUM>, whereby the receiving node can use the public key of the transmitting node to verify that the integrity check value in fact has been generated by the transmitting node and then perform e.g. hashing and compare with the received hash value to verify integrity of the message.

To sum up, the security related information may comprise one or more of:.

<FIG> is a schematic flowchart relating to an example of security related information in a LLDP message and of how involved nodes may exchange information to e.g. handle the security related information. In other words, <FIG> is a detailed example of what was discussed in the preceding paragraph. In the shown example the LLDP message is transmitted by a transmitting node abbreviated TN that may correspond to the transmitting node <NUM> discussed above, and received by a receiving node abbreviated RN that may correspond to the receiving node <NUM> discussed above. The shown LLDP message has a mandatory part and an optional part. The optional part may correspond to organizational specific TLVs. The security related information is in the shown example comprised in the optional part and enables to verify authenticity of the transmitting node and integrity of the message.

The authenticity verification is enabled by a public (cryptographic) key of the transmitting node, abbreviated TN PuK, that has been signed by a security administrating node that may correspond to the security administrating node <NUM> discussed above, e.g. a CA server, or more specifically by a private (cryptographic) key thereof, abbreviated SAN PiK. What here enables the authenticity verification of the transmitting node is thus what is abbreviated (TN PuK)s^(SAN PIK) in the figure, where s^ stands for "signed by".

The message integrity verification is enabled by a hash (sum) regarding e.g. the rest of the LLDP message and the hash is then signed by the transmitting node, or more specifically by a private (cryptographic) key thereof, abbreviated TN PiK. What here enables the message integrity verification authentication is thus what is abbreviated (Hash)s^(TN PIK).

Before sending the LLDP message, the transmitting node <NUM> thus have to obtain, e.g. be configured with and/or generate, certain information, that may involve exchanging information with the security administrating node <NUM>, e.g. as part of node setup or installation phase and/or initial node configuration.

The transmitting node <NUM> may e.g. generate and/or be configured with a public key and a private key of a cryptographic key pair associated with the transmitting node <NUM>. The public key thereof, i.e. TN PUK may be sent to the security administrating node <NUM> to be signed by its private key, i.e. SAN PiK, and the transmitting node <NUM> may thus receive back the (TN PUK)s^(SAN PiK). The transmitting node <NUM> may also from the security administrating node <NUM> receive its public key, i.e. SAN PuK, whereby the transmitting node <NUM> becomes able to verify signatures made by the security administrating node <NUM>, e.g. verify that a signature said to be made by the security administrating node <NUM> actually made by it.

It is realized that multiple nodes may be configured correspondingly as described for the transmitting node <NUM> above. This is illustrated in the figure for the receiving node <NUM>. These nodes can then transmit and/or receive LLDP messages with security related information and use it for node authentication and/or message integrity verification and/or to transmit/receive encrypted content.

In the figure, the receiving node <NUM> receives, in the LLDP message, the TN PuK that also corresponds to an identifier of the transmitting node <NUM>, and is able to verify its authenticity since it is signed by the security administrating node <NUM>, i.e. (TN PuK)s^(SAN PiK) and the receiving node <NUM> has access to the public key of the security administrating node <NUM>, i.e. SAN PuK. When having the TN PuK and that is verified authentic, the receiving node <NUM>'<NUM> can use it to verify that the hash is actually generated by the transmitting node <NUM>, i.e. that the hash is authentic, and/or decrypt it. The hash can then be used by the receiving node <NUM> to verity the integrity of the LLDP message. In some examples, not shown here, the nodes, e.g. the transmitting node <NUM> and/or the receiving node <NUM> may also or alternatively be configured with public keys of other nodes that have been signed by a security administrating node, e.g. the transmitting node <NUM> may e.g. also receive the (RN PuK)s^(SAN PiK) from the security administrating node <NUM> and the receiving node <NUM> may also receive the (TN PuK)s^(SAN PiK) from the security administrating node <NUM>. In these examples, these public keys, that thus typically correspond to identifiers of said other nodes, can be used as an extra security step to compare with the public key of the LLDP message where both public keys, obtained via two different paths, need to be the same to be verified ok. Alternatively, the public key may in this case not be needed to be sent in the LLDP message, or it can be sent but be signed or be encrypted by the transmitting node <NUM> using the public key of the receiving node <NUM> instead.

When a node, e.g. the receiving node <NUM>, has the public key of another node, e.g. the transmitting node <NUM>, it can use it to e.g. encrypt content to be sent to this node in a next step, e.g. to accomplish encrypted content in a LLDP message as discussed above.

<FIG> is a schematic block diagram to illustrate encrypted content in a LLDP message as discussed above in connection with <FIG>. A certain TLV of a conventional LLDP message may be assigned to be or act as a container of encrypted content. The transmitting and receiving node "know" this, e.g. may be configured so that the TLV with encrypted content is identified and can be managed accordingly. The content of this TLV may be one or more TLVs in cleartext that have been encrypted and thus have become one or more encrypted TLVs.

The solutions and examples discussed above in relation to <FIG> are advantageous used with embodiments herein as will be described next. However, also solutions based on the prior art security protocols mentioned in the Background can be used to accomplish security regarding e.g. authentication and message integrity, and then be used with embodiments herein, although these protocols may result in undesired side effects in some situations as mentioned above, e.g. regarding unnecessary processing and overhead and thereby unnecessary energy consumption and/or reduced performance. , but that can be avoided by the solution discussed above in relation to <FIG>.

<FIG> depicts another combined signalling diagram and flowchart, which will be used to exemplify and discuss some embodiments herein. The transmitting and/or receiving nodes <NUM>-<NUM> have been selected as examples of network nodes in the communication network <NUM> and the first management node <NUM> as an example of a management node.

The nodes <NUM>-<NUM> may obtain security status information regarding neighbouring network nodes based on one or more LLDP messages received from the neighboring network nodes. That is, node <NUM> may obtain security status information regarding nodes <NUM> and/or <NUM>, node <NUM> regarding nodes <NUM> and/or <NUM>, node <NUM> regarding nodes <NUM> and/or <NUM>, node <NUM> regarding nodes <NUM> and/or <NUM>, and node <NUM> regarding nodes <NUM> and/or <NUM> and/or <NUM>. The security status information regarding a neighbouring node may correspond to the security status discussed above. Each node may thus store, e.g. in its MIB, security status about its neighbouring nodes, e.g. regarding one or more communication ports thereof, typically such that the node has received LLDP messages from. The security status regarding a neighbouring node, such as stored by the node <NUM> regarding the node <NUM>, may be regarding one or more communication ports thereof, and may indicate if the neighbouring network node, e.g. the node <NUM> or communication port(s) thereof, has been verified to be authentic and/or if it has been verified to be not authentic.

Note that it may be predefined and/or predetermined that if a node is not indicated as verified to be authentic, this is to be seen as an indication of the node as verified to be not authentic, or the opposite way around. In some embodiments, for security reasons, a node that is not indicated as verified to be authentic, shall be considered and/or shall be assumed to be verified as not authentic.

Obtain may here involve receiving one or more LLDP messages from a neighbouring node and process these messages, such as verify the authenticity based on the LLDP messages or security related information thereof as discussed above. Alternatively, to obtain security status information regarding a neighbouring node may involve receiving and/or processing some other information that result in security status regarding that neighbouring node, e.g. regarding one or more communication ports thereof. A node could e.g. alternatively obtain security status based on some of the prior art methods mention in the Background and separately receive conventional LLDP messages from neighbouring nodes and then e.g. store information in its MIB based on the LLDP messages and/or based on the obtained security status information.

In any case, a node, e.g. the node <NUM>, may store the security status information together with information obtained from one or more LLDP messages received from the same neighbouring node, e.g. node <NUM>, or communication port(s) thereof, that the security status is valid for, e.g. store it in a database such as MIB of the node, e.g. the node <NUM>.

At least some of the nodes, e.g. nodes <NUM>-<NUM>, that in the previous action obtained the security status information may transmit, or send, the security status information to a management node, e.g. the management node <NUM>, that may receive or retrieve this information. Said at least some of the nodes <NUM>-<NUM> are in the following assumed to be the nodes <NUM> and <NUM>.

In any case, the transmitted and received information may be named LLDP information, which LLDP information is information obtained, typically compiled, by said nodes, i.e. for example node <NUM>, based on one or more LLDP messages received from neighbouring network nodes. That is, in the case of node <NUM>, based on one or more LLDP messages received from nodes <NUM> and/or <NUM>. The LLDP information thus comprises the security status information. The LLDP information may correspond to or be a MIB that may be a conventional MIB that has been extended with security status information and possibly also other information as discussed above.

The management node <NUM> may thus utilize security status information received with LLDP information from nodes, e.g. nodes <NUM>-<NUM>, which security status indicates which neighbouring network nodes to said nodes that have been verified to be authentic and/or which that have been verified to be not authentic. This enables the management node <NUM> that to take into account whether nodes, e.g. discovered via a discovery procedure based on LLDP messages, are authenticated and/or which are not. This enables improved security in the communication network <NUM> and an improvement regarding how network nodes can be managed based on LLDP messages in the communication network. Conventionally, management based on LLDP messages are based on MIBs compiled based on information from LLDP messages, but there is no security status information involved as in embodiments herein.

A further advantage with embodiments herein if used with the solutions discussed above in relation to <FIG> is that these solutions are based on security related information in LLDP messages, with facilitates providing the LLDP information, e.g. MIBs, with security status information compared to if conventional LLDP messages are received and authenticity is verified separately, i.e. not based on the LLDP messages.

The management node <NUM> may then provide, e.g. generating and/or updating, a topology map regarding the communication network <NUM> based on the received LLDP information and the security status information. The topology map may be a conventional one e.g. as may be provided based on information from conventional MIBs, such as used for SDN, but where the security status information has been taken into account, for example may the security status of nodes been taking into account, e.g. that the topology map may be classified based on it or that certain parts of it are classified as secure or more secure than other parts, based on the security status information. Depending on a setting and/or configuration of the management node <NUM>, the topology map may only utilize and/or be based on and/or prioritise nodes and/or ports thereof, that according to the security status information are secure, such as verified to be authentic. This makes it possible to provide a much more versatile and usable topology map, especially in situations where security is of particular importance.

Further, the management node <NUM> may configure and/or reconfigure, based on the received security status information and/or the topology map, one or more of said network nodes, e.g. one or more of nodes <NUM>-<NUM>, regarding security. For example, the management node may provide a new or updated configuration, such as discussed above, for one or more of said nodes. Alternatively or additionally the management node <NUM> may configure or reconfigure one or more of the nodes so they can change from being not verified authentic to become verified as authentic. For example, if the security status indicates the node <NUM> to be not verified authentic, the management node <NUM> may configure it, such as update a software and/or configure it with cryptographic keys and/or activate a stricter security policy within the node <NUM> so e.g. node <NUM> when receiving a next LLDP message from node <NUM> can verify it as authentic. Note that the management node <NUM> may (re)configure one or more of nodes, e.g. one or more of nodes <NUM>-<NUM>, that it did not receive any LLDP information from since the LLDP information is about neighbouring nodes and e.g. node <NUM> is neighbouring node <NUM>. Also, the management node <NUM> may even (re)configure node(s) not identified by the LLDP information since such node(s), e.g. one or more of nodes <NUM>-<NUM>, may still be identified by the topology map or be known in some other way by the management node <NUM>. When such node(s) are not identified by the LLDP information, the management node <NUM> may as a result e.g. attempt to (re)configure the node(s) to become identifiable and/or be identified next by LLDP information and/or to transmit LLDP messages with security related information, or the management node <NUM> may attempt to switch such node(s) off if it e.g. can be assumed that such node(s) is not secure.

Hence, to configure and/or reconfigure said one or more of the network nodes, e.g. nodes <NUM>-<NUM>, may comprise to change configuration of one or more of the network nodes, e.g. node <NUM>, so they, or it, will communicate using LLDP messages, respectively, that comprises security related information, e.g. as discussed above. That is, security related information enabling to verify authenticity of the node, e.g. communication port(s) thereof, transmitting such LLDP message and/or enabling to verify integrity of such LLDP message. For example, so that node <NUM> will transmit LLDP messages with security related information that enables, e.g. node <NUM>, to verify authenticity the node <NUM>.

In other words, to configure and/or reconfigure said one or more of the network nodes may comprises to configure one or more of the network nodes, e.g. node <NUM>, with security related elements required to accomplish said security related information. The security related element may e.g. be one or more of the cryptographic keys as mentioned above or other elements that may be associated with, e.g. referenced by, the configuration of a node as discussed above.

Moreover, to configure and/or reconfigure said one or more of the network nodes, e.g. nodes <NUM>-<NUM>, may comprise to configure at least one of said network nodes, e.g. node <NUM> or all of the nodes, to communicate using LLDP messages with encrypted content, e.g. as discussed above, where the encrypted content contains encrypted one or one or more TLVs being cleartext TLVs that have been encrypted.

The present action thus further improves security and enables e.g. to provide a sufficiently secure SDN even though nodes to be used in the communication network <NUM>, e.g. according to the topology map, are not sufficiently secure to begin with.

In general, the management node <NUM> may manage the communication network <NUM> based on the received security status information so that communication through network nodes that have been verified to be authentic will be prioritized. For example, if nodes <NUM>-<NUM> have been verified to be authentic, communication through these, and e.g. in the first network domain 101a, may be prioritized over communication through other network nodes and/or in other network domains.

Said prioritization may e.g. be accomplished through the topology map, e.g. by updating it based on (new) security information received after the topology map was provided in the above action, or just to update a routing table or similar that makes sure that communication is taking part only or prioritized through, or become possible, only through network nodes that are considers secure, e.g. that have been verified authentic according to the security status information. The present action may involve defining and/or managing and/or operating a SDN on the communication network <NUM>. One or more of the previous actions <NUM>-<NUM> may be considered part of the present action or the present action may be considered relating to further management of the communication network <NUM>.

In any case, the present action enables further improvements regarding security.

As should be recognized, "to prioritize" communication through certain network nodes over other network nodes can be accomplished in many different ways. For example, that that only prioritized nodes are allowed for communication, or that, at least first, only prioritized network nodes are considered and/or used for communication. If the prioritized nodes are sufficient to accomplish a desired or required communication, other nodes can completely be left out, else one at a time of the other nodes can be considered and used, then more of them, but thus only when there is no prioritized node to use instead, until a desired or required communication is accomplished. Another way is to first always select a prioritized node if many nodes are possible to use, e.g. when it is set forth to find a certain route or communication path in the communication network <NUM>. If a prioritized node is not selectable or possible to find at some point, another non-prioritized node is selected, or a "step back" is performed until another prioritized node is selected and then a new attempt is made to see if it is possible to continue via another path where only or more prioritized nodes are involved, etc. In general, as should be recognized by the skilled person, to prioritize communication through certain nodes, such as through prioritized nodes, can be seen as maximising use and/or involvement of these prioritized nodes, i.e. corresponds to an optimization problem.

<FIG> is a flowchart schematically illustrating embodiments of a method performed by a management node, e.g. the management node <NUM> or <NUM> although the management node <NUM> will be used as an example in the following. The method is for supporting management of network nodes, e.g. the transmitting and/or receiving network nodes, or simply nodes, <NUM>-<NUM>, comprised in a communication network, e.g. the communication network <NUM>.

The method comprises the following actions, which actions may be taken in any suitable order and/or be carried out fully or partly overlapping in time when this is possible and suitable.

The management node <NUM> receives, from at least some of said network nodes, e.g. from nodes <NUM>, <NUM>, LLDP information, which LLDP information is information obtained by said nodes based on one or more LLDP messages received from neighboring network nodes, e.g. nodes <NUM>-<NUM>. That is, nodes that are neighbouring said at least some network nodes. The LLDP information comprises security status information regarding said neigbouring network nodes, e. g nodes <NUM>-<NUM>, wherein the security status information regarding a neighbouring network node, e.g. node <NUM>, indicates if the neighbouring network node, e.g. node <NUM>, has been verified to be authentic and indicates if the neighbouring network node, e.g. node <NUM>, has been verified to be not authentic.

This action may fully or partly correspond to actions 501a-b.

The management node <NUM> may provide a topology map regarding the communication network <NUM> based on the received LLDP information and the security status information.

This action may fully or partly correspond to action <NUM>.

The management node <NUM> may configure, based on the received security status information and/or the topology map, one or more of said network nodes, exemplified by nodes <NUM>-<NUM>, regarding security.

To configure may here comprise to change configuration of one or more of said network nodes, e.g. some, such as nodes <NUM>-<NUM>, of nodes <NUM>-<NUM>, so they will transmit LLDP messages, respectively, that comprises security related information enabling to verify authenticity of the node transmitting such LLDP message and/or enabling to verify integrity of such LLDP message.

In some embodiments, to configure may here comprise to configure one or more of said network nodes, e.g. some, such as nodes <NUM>-<NUM>, of nodes <NUM>-<NUM>, with security related elements required to accomplish said security related information.

Further, in some embodiments, to configure may here comprise to configure one or more of said network nodes, e.g. some, such as nodes <NUM>-<NUM>, of nodes <NUM>-<NUM>, to communicate using LLDP messages with encrypted content, which encrypted content contains encrypted one or one or more TLVs being cleartext TLVs that have been encrypted.

The management node <NUM> may manage at least part of the communication network <NUM> based on the security status information so that communication through network nodes that have been verified to be authentic will be prioritized.

<FIG> is a schematic block diagram for illustrating embodiments of a management node, e.g. the management node <NUM> or <NUM>, in the figure and in the following exemplified as the management node <NUM>. The management node is for supporting management of network nodes, e.g. the transmitting and/or receiving network nodes, or simply nodes, <NUM>-<NUM>, comprised in a communication network, e.g. the communication network <NUM>.

The figure is particularly for illustrating how the management node may be configured to perform the method and actions discussed above in connection with <FIG>.

The management node <NUM> may comprise a processing module <NUM>, such as a means, one or more hardware modules, including e.g. one or more processors, and/or one or more software modules for performing said methods and/or actions.

The management node <NUM> may further comprise a memory <NUM> that may comprise, such as contain or store, a computer program <NUM>. The computer program <NUM> comprises 'instructions' or 'code' directly or indirectly executable by the management node <NUM> so that it performs said method and/or actions. The memory <NUM> may comprise one or more memory units and may be further be arranged to store data, such as configurations and/or applications involved in or for performing functions and actions of embodiments herein.

Moreover, the management node <NUM> may comprise a processing circuit <NUM> as an exemplifying hardware module and may comprise or correspond to one or more processors. In some embodiments, the processing module <NUM> may comprise, e.g. 'is embodied in the form of' or 'realized by' the processing circuit <NUM>. In these embodiments, the memory <NUM> may comprise the computer program <NUM> executable by the processing circuit <NUM>, whereby the management node <NUM> is operative, or configured, to perform said method and/or actions.

Typically, the management node <NUM>, e.g. the processing module <NUM>, comprises an Input/Output (I/O) module <NUM>, configured to be involved in, e.g. by performing, any communication to and/or from other units and/or nodes. The I/O module <NUM> may be exemplified by an obtaining, e.g. receiving, module and/or a providing, e.g. sending or transmitting, module, when applicable.

In further embodiments, the management node <NUM>, e.g. the processing module <NUM>, may comprise one or more of a receiving module <NUM>, a providing module <NUM>, a configuring module <NUM>, and a managing module <NUM> as exemplifying hardware and/or software module(s).

In some embodiments, the receiving module <NUM>, the providing module <NUM>, the configuring module <NUM> and the managing module <NUM>, may be fully or partly implemented by the processing circuit <NUM>.

Therefore, according to the various embodiments described above, the management node <NUM>, and/or the processing module <NUM> and/or the processing circuit <NUM> and/or the receiving module <NUM> and/or the I/O module <NUM>, are operative, or configured, to receive, from at least some of said network nodes, e.g. from nodes <NUM>, <NUM>, said LLDP information, which LLDP information is information obtained by said nodes based on one or more LLDP messages received from neighboring network nodes, e.g. nodes <NUM>-<NUM>. That is, nodes that are neighbouring said at least some network nodes. As already discussed above in connection with <FIG>, the LLDP information comprises security status information regarding said neigbouring network nodes, e.g. nodes <NUM>-<NUM>, wherein the security status information regarding a neighbouring network node, e.g. node <NUM>, indicates if the neighbouring network node, e.g. node <NUM>, has been verified to be authentic and indicates if the neighbouring network node, e.g. node <NUM>, has been verified to be not authentic.

Moreover, the management node <NUM>, and/or the processing module <NUM> and/or the processing circuit <NUM> and/or the providing module <NUM> and/or the I/O module <NUM>, may be operative, or configured, to provide said topology map regarding the communication network <NUM> based on the received LLDP information and the security status information.

Furthermore, the management node <NUM>, and/or the processing module <NUM> and/or the processing circuit <NUM> and/or the configuring module <NUM> and/or the I/O module <NUM>, may be operative, or configured, to configure, based on the received security status information and/or the topology map, said one or more of said network nodes, exemplified by nodes <NUM>-<NUM>, regarding security.

Further, the management node <NUM>, and/or the processing module <NUM> and/or the processing circuit <NUM> and/or the managing module <NUM> and/or the I/O module <NUM>, may be operative, or configured, to manage at least part of the communication network <NUM> based on the security status information so that communication through network nodes that have been verified to be authentic will be prioritized.

<FIG> is a schematic drawing illustrating embodiments relating to computer program(s) and carriers thereof to cause the management node discussed above, e.g. the management node <NUM>, to perform the method actions. The computer program may be the computer program <NUM> and comprises instructions that when executed by the processing circuit <NUM> and/or the processing module <NUM> causes the management node, e.g. the management node <NUM>, to perform as described above. In some embodiments there is provided a carrier, or more specifically a data carrier, e.g. a computer program product, comprising the computer program <NUM>. The carrier may be one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium, e.g. a computer readable storage medium <NUM> as schematically illustrated in the figure. The computer program <NUM> may thus be stored on the computer readable medium <NUM>. By carrier may be excluded a transitory, propagating signal and the data carrier may correspondingly be named non-transitory data carrier. Non-limiting examples of the data carrier being a computer readable storage medium is a memory card or a memory stick, a disc storage medium such as a CD or DVD, or a mass storage device that typically is based on hard drive(s) or Solid State Drive(s) (SSD). The computer readable storage medium <NUM> may be used for storing data accessible over a computer network <NUM>, e.g. the Internet or a Local Area Network (LAN). The computer program <NUM> may furthermore be provided as a pure computer program or comprised in a file or files. The file or files may be stored on the computer readable storage medium <NUM> and e.g. available through download e.g. over the computer network <NUM> as indicated in the figure, e.g. via a server. The server may e.g. be a web or File Transfer Protocol (FTP) server. The file or files may e.g. be executable files for direct or indirect download to and execution on the management node <NUM> to make it perform as described above, e.g. by execution by the processing circuit <NUM>. The file or files may also or alternatively be for intermediate download and compilation involving the same or another processor to make them executable before further download and execution causing the management node <NUM> to perform as described above.

Note that any processing module(s) mentioned in the foregoing may be implemented as a software and/or hardware module, e.g. in existing hardware and/or as an Application Specific Integrated Circuit (ASIC), a field-programmable gate array (FPGA) or the like. Also note that any hardware module(s) and/or circuit(s) mentioned in the foregoing may e.g. be included in a single ASIC or FPGA, or be distributed among several separate hardware components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

Those skilled in the art will also appreciate that the modules and circuitry discussed herein may refer to a combination of hardware modules, software modules, analogue and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in memory, that, when executed by the one or more processors may make the management node <NUM> to be configured to and/or to perform the above-described method.

Identification by any identifier herein may be implicit or explicit. The identification may be unique in the communication network <NUM> or at least in a relevant part or area thereof.

The term "network node" or simply "node" as used herein may as such refer to any type of node that may communicate with another node in and be comprised in a communication network, e.g. the communication network <NUM>. Such node may e.g. be a transport network node and/or e.g. an Ethernet node as mentioned above. Further, such node may be or be comprised in a radio network node (described below) or any network node, which e.g. may communicate with a radio network node. Examples of such network nodes include any radio network node, a core network node, Operations & Maintenance (O&M), Operations Support Systems (OSS), Self Organizing Network (SON) node, etc..

The term "radio network node" as may be used herein may as such refer to any type of network node for serving a wireless device, e.g. a so called User Equipment, and/or that are connected to other network node(s) or network element(s) or any radio node from which a wireless device receives signals from. Examples of radio network nodes are Node B, Base Station (BS), Multi-Standard Radio (MSR) node such as MSR BS, eNB, eNodeB, network controller, RNC, Base Station Controller (BSC), relay, donor node controlling relay, Base Transceiver Station (BTS), Access Point (AP), New Radio (NR) node, transmission point, transmission node, node in distributed antenna system (DAS) etc..

Each of the terms "wireless device", "user equipment" and "UE", as may be used herein, may as such refer to any type of wireless device arranged to communicate with a radio network node in a wireless, cellular and/or mobile communication system, and may thus be referred to as a wireless communication device. Examples include: target devices, device to device UE, device for Machine Type of Communication (MTC), machine type UE or UE capable of machine to machine (M2M) communication, Personal Digital Assistant (PDA), iPAD, Tablet, mobile, terminals, smart phone, Laptop Embedded Equipment (LEE), Laptop Mounted Equipment (LME), Universal Serial Bus (USB) dongles etc..

While some terms are used frequently herein for convenience, or in the context of examples involving other a certain, e.g. 3GPP or other standard related, nomenclature, it must be appreciated that such term as such is non-limiting.

Also note that although terminology used herein may be particularly associated with and/or exemplified by certain communication systems or networks, this should as such not be seen as limiting the scope of the embodiments herein to only such certain systems or networks etc..

As used herein, the term "memory" may refer to a data memory for storing digital information, typically a hard disk, a magnetic storage, medium, a portable computer diskette or disc, flash memory, random access memory (RAM) or the like. Furthermore, the memory may be an internal register memory of a processor.

Also note that any enumerating terminology such as first node, second node, first base station, second base station, etc., should as such be considered non-limiting and the terminology as such does not imply a certain hierarchical relation. Without any explicit information in the contrary, naming by enumeration should be considered merely a way of accomplishing different names.

As used herein, the expression "configured to" may mean that a processing circuit is configured to, or adapted to, by means of software or hardware configuration, perform one or more of the actions described herein.

As used herein, the terms "number" or "value" may refer to any kind of digit, such as binary, real, imaginary or rational number or the like. Moreover, "number" or "value" may be one or more characters, such as a letter or a string of letters. Also, "number" or "value" may be represented by a bit string.

As used herein, the expression "may" and "in some embodiments" has typically been used to indicate that the features described may be combined with any other embodiment disclosed herein.

In the drawings, features that may be present in only some embodiments are typically drawn using dotted or dashed lines.

As used herein, the expression "transmit" and "send" are typically interchangeable. These expressions may include transmission by broadcasting, uni-casting, group-casting and the like. In this context, a transmission by broadcasting may be received and decoded by any authorized device within range. In case of uni-casting, one specifically addressed device may receive and encode the transmission. In case of group-casting, e.g. multicasting, a group of specifically addressed devices may receive and decode the transmission.

When using the word "comprise" or "comprising" it shall be interpreted as nonlimiting, i.e. meaning "consist at least of".

The embodiments herein are not limited to the above described preferred embodiments. Various alternatives and modifications may be used.

Claim 1:
A method, performed by a management node (<NUM>; <NUM>), for supporting management of network nodes (<NUM>-<NUM>; <NUM>-<NUM>) comprised in a communication network (<NUM>), wherein the method comprises:
- receiving (501a-b; <NUM>), from at least some of said network nodes (<NUM>, <NUM>), Link Layer Discovery Protocol, "LLDP", information, which LLDP information is information obtained by said nodes based on one or more LLDP messages received from neighboring network nodes (<NUM>-<NUM>) that are neighbouring said at least some network nodes (<NUM>, <NUM>), the LLDP information comprising security status information regarding said neigbouring network nodes (<NUM>-<NUM>), wherein the security status information regarding a neighbouring network node (<NUM>) indicates if the neighbouring network node (<NUM>) has been verified to be authentic and indicates if the neighbouring network node (<NUM>) has been verified to be not authentic.