[OVSDB-268] LLDP Spoofing attack warning when using Openstack with ODL Cluster (both features) Created: 21/Jan/16  Updated: 11/Feb/16  Resolved: 11/Feb/16

Status: Resolved
Project: ovsdb
Component/s: openstack.net-virt
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Venkatrangan Govindarajan Assignee: Anil Vishnoi
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 5040
Priority: High

 Description   

When using Openstack and 3 node ODL cluster, with one ODL to handle neutron requests and the other two members as Managers in the OVS of Openstack. There were repeated warning messages in karf.log of one of the nodes

ogress.
2016-01-20 19:28:49,585 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.
2016-01-20 19:28:54,582 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.
2016-01-20 19:28:54,592 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.
2016-01-20 19:28:59,583 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.
2016-01-20 19:28:59,584 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.



 Comments   
Comment by Venkatrangan Govindarajan [ 21/Jan/16 ]

Used stable/beryllium code

Comment by Sam Hague [ 22/Jan/16 ]

Anil, any idea what this lldp spoofing warning is? Is this a new feature?

Comment by Anil Vishnoi [ 22/Jan/16 ]

Sam,
I think there was a security vulnerability fix related to LLDP spoofing went in openflowplugin (a while back) and that fix is probably determining that LLDP spoof is happening.

Venkat, i never seen it in my environment, can you dump the rules on the OVS switches and see if there is drop rule installed or not.

Comment by Anil Vishnoi [ 02/Feb/16 ]

venkat, i tried this locally with the same setup as yours and i am not seeing this issue. Can you please dump the output of "ovs-vsctl show" on all the nodes + flows installed on all the bridges on these nodes.

Comment by Venkatrangan Govindarajan [ 02/Feb/16 ]

Anil,
Reted today also with the below setup

ODL1 -> Neutron Requests
ODL2/ODL3 for handling the OVS/Openflow

Still only ODL3 has the warning.

Comment by Venkatrangan Govindarajan [ 02/Feb/16 ]

ovs-vsctl show

control node:
ubuntu@odl-os-control-node:~/devstack$ sudo ovs-vsctl show
7379aa64-0416-45e2-9531-351397cc742a
Manager "tcp:11.12.13.5:6640"
is_connected: true
Manager "tcp:11.12.13.4:6640"
is_connected: true
Bridge br-ex
Controller "tcp:11.12.13.5:6653"
is_connected: true
Controller "tcp:11.12.13.4:6653"
is_connected: true
fail_mode: secure
Port br-ex
Interface br-ex
type: internal
Port "eth2"
Interface "eth2"
Port patch-int
Interface patch-int
type: patch
options:

{peer=patch-ext}
Bridge br-int
Controller "tcp:11.12.13.5:6653"
is_connected: true
Controller "tcp:11.12.13.4:6653"
is_connected: true
fail_mode: secure
Port "vxlan-12.14.16.3"
Interface "vxlan-12.14.16.3"
type: vxlan
options: {key=flow, local_ip="12.14.16.2", remote_ip="12.14.16.3"}
Port "tap1b35eb29-c3"
Interface "tap1b35eb29-c3"
Port br-int
Interface br-int
type: internal
Port "tapc741c740-b3"
Interface "tapc741c740-b3"
Port "tap92b1f549-b3"
Interface "tap92b1f549-b3"
type: internal
Port patch-ext
Interface patch-ext
type: patch
options: {peer=patch-int}
Port "tapf58200cd-00"
Interface "tapf58200cd-00"
type: internal
ovs_version: "2.3.2"


compute node:
ubuntu@odl-os-compute-node:~/devstack$ sudo ovs-vsctl show
bf460c25-5849-4874-9758-4fcbafbf9f5e
Manager "tcp:11.12.13.5:6640"
is_connected: true
Manager "tcp:11.12.13.4:6640"
is_connected: true
Bridge br-ex
Controller "tcp:11.12.13.5:6653"
is_connected: true
Controller "tcp:11.12.13.4:6653"
is_connected: true
fail_mode: secure
Port "eth2"
Interface "eth2"
Port br-ex
Interface br-ex
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-ext}

Bridge br-int
Controller "tcp:11.12.13.4:6653"
is_connected: true
Controller "tcp:11.12.13.5:6653"
is_connected: true
fail_mode: secure
Port br-int
Interface br-int
type: internal
Port "tapfe0a3251-16"
Interface "tapfe0a3251-16"
Port patch-ext
Interface patch-ext
type: patch
options:

{peer=patch-int}

Port "tap547166bc-d8"
Interface "tap547166bc-d8"
Port "vxlan-12.14.16.2"
Interface "vxlan-12.14.16.2"
type: vxlan
options:

{key=flow, local_ip="12.14.16.3", remote_ip="12.14.16.2"}

ovs_version: "2.3.2"

Comment by Venkatrangan Govindarajan [ 02/Feb/16 ]

Control Node
br-int lldp flows

cookie=0x0, duration=3298.189s, table=0, n_packets=908, n_bytes=101696, dl_type=0x88cc actions=CONTROLLER:65535

br-ex
ubuntu@odl-os-control-node:~/devstack$ sudo ovs-ofctl dump-flows br-ex -OOpenflow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=3374.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
cookie=0x0, duration=3374.887s, table=0, n_packets=1070, n_bytes=119710, dl_type=0x88cc actions=CONTROLLER:65535

Comment by Venkatrangan Govindarajan [ 02/Feb/16 ]

Compute Node

br-ex has no flows installed. br-int has the lldp flows as needed

Comment by Venkatrangan Govindarajan [ 03/Feb/16 ]

Other clues:

Always happens in ODL3 when ODL2 and ODL3 are used as OVS Managers and Controllers for testing. the warning occurs every second.

ODL3 is the owner for all the entities, I think since br-ex is connected to public network, Maybe that is causing this error.
{
"entity-owners": {
"entity-type": [
{
"type": "ovsdb",
"entity": [
{
"id": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://uuid/7379aa64-0416-45e2-9531-351397cc742a']",
"candidate": [

{ "name": "member-3" }

,

{ "name": "member-2" }

],
"owner": "member-3"
},
{
"id": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://uuid/bf460c25-5849-4874-9758-4fcbafbf9f5e']",
"candidate": [

{ "name": "member-3" }

,

{ "name": "member-2" }

],
"owner": "member-3"
}
]
},
{
"type": "ovsdb-netvirt-provider",
"entity": [
{
"id": "/general-entity:entity[general-entity:name='ovsdb-netvirt-provider']",
"candidate": [

{ "name": "member-3" }

,

{ "name": "member-2" }

,

{ "name": "member-1" }

],
"owner": "member-3"
}
]
},
{
"type": "openflow",
"entity": [
{
"id": "/general-entity:entity[general-entity:name='openflow:49213346451329']",
"candidate": [

{ "name": "member-3" }

,

{ "name": "member-2" }

],
"owner": "member-3"
},
{
"id": "/general-entity:entity[general-entity:name='openflow:86756597698629']",
"candidate": [

{ "name": "member-3" }

,

{ "name": "member-2" }

],
"owner": "member-3"
},
{
"id": "/general-entity:entity[general-entity:name='openflow:49213351373018']",
"candidate": [

{ "name": "member-3" }

,

{ "name": "member-2" }

],
"owner": "member-3"
},

{ "id": "/general-entity:entity[general-entity:name='openflow:82054700722251']", "owner": "" }

,
{
"id": "/general-entity:entity[general-entity:name='openflow:217913872071744']",
"candidate": [

{ "name": "member-3" }

,

{ "name": "member-2" }

],
"owner": "member-3"
},

{ "id": "/general-entity:entity[general-entity:name='openflow:90510897257539']", "owner": "" }

]
},
{
"type": "ovsdb-southbound-provider",
"entity": [
{
"id": "/general-entity:entity[general-entity:name='ovsdb-southbound-provider']",
"candidate": [

{ "name": "member-3" }

,

{ "name": "member-2" }

,

{ "name": "member-1" }

],
"owner": "member-3"
}
]
}
]
}
}

Comment by Venkatrangan Govindarajan [ 03/Feb/16 ]

(In reply to Venkatrangan Govindarajan from comment #8)
> Compute Node
>
> br-ex has no flows installed. br-int has the lldp flows as needed

Will need to add this as a seperate bug

Comment by Anil Vishnoi [ 10/Feb/16 ]

In clustered environment, if two devices are owner by two different controller, LLDP packet sent by one controller node will go to another controller node through it's connected device. Currently we have a fix for security vulnerability fix that check if that LLDP packet was send by the same controller node and if not, it will spit the warning message reported in this bug. In 3 node cluster that's a very valid scenario, because different devices are connected to different controller node, but because of the existing security fix, it will spit warning message because that packet was not sent by the same controller. This requires a fix at the openflowplugin application level and it's not an easy fix from security perspective.

Net-virt don't usse any of the topology information because it's end host based solution, so we don't really want lldp speaker to send lldp packets to the switch. I disabled the lldp speaker for net-virt using the following patch

https://git.opendaylight.org/gerrit/#/c/34420/1

Generated at Wed Feb 07 20:35:56 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.