Disable STP in reset_port()

[henn]

With STP enabled, it can take 30 seconds for DHCP to complete. For situations like BMI, where we PXE boot then boot iPXE, this can add a minute or more to the boot time.

As part of the port initialization in reset_port(), we should disable STP.

It might be a security issue to give untrusted tenants access to STP anyhow (they could mess with the spanning tree and maybe create loopbacks?).

Thoughts?

[pjd-nu]

On May 18, 2017, at 11:25 AM, Jason Hennessey notifications@github.com wrote: It might be a security issue to give untrusted tenants access to STP anyhow (they could mess with the spanning tree and maybe create loopbacks?).

It's definitely a denial of service opportunity if a tenant has access to Spanning Tree. Good call.

..................................................................... Peter Desnoyers pjd@ccs.neu.edu Northeastern Computer & Information Science (617) 373-8683

[zenhack]

It occurs to me that maybe we ought to try to find a more systematic way to make sure what we're exposing is sane; I wouldn't be at all surprised if this wasn't the only hole.

[naved001]

I am feeling a little out of the loop here.

As part of the port initialization in reset_port(), we should disable STP.

1. Are we talking about revert_port() here or do we want to add a different reset_port() in future (and if yes, what would reset_port() do?)
2. At the moment there's no port initialization. This is something I suggested we do #761

to give untrusted tenants access to STP anyhow

When are we ever exposing access to STP at all?

Edit:

(they could mess with the spanning tree and maybe create loopbacks?).

Also, why should we outright disable it? I am no networking guru, but we have STPs to prevent loopbacks. We should just not be exposing this to tenants.

[zenhack]

I'm not entirely clear at what level STP comes into play? Are we just talking about telling the switch not to negotiate STP with stuff on that port?

It occurs to me that you could use the normal api operations to construct a topology that allows for loops; if we "disable STP" in whatever manner we're referring to, is that going to prevent those hosts from dealing with the situation internally? I don't know enough about the details of the protocol -- is it possible to just have the switch not do STP over that port, but still allow STP traffic between hosts on a VLAN?

[henn]

@naved001 - yes, revert_port(), and my suggestion is to do this subsequent to #761.

@zenhack - the proposal is to disable STP negotiation with untrusted tenant ports.

Here is a Cisco quote on the security risks:

STP is a useful protocol but, unfortunately, both versions of the protocol were conceived with no security in mind and, as a result, are both vulnerable to several types of attacks. STP does not implement any authentication and encryption to protect the exchange of BPDUs. Because of the lack of authentication, anyone can speak to a STP-enabled device. An attacker could very easily inject bogus BPDUs, triggering a topology recalculation. A forced change to the STP topology could lead to a denial of service condition, or leave the attacker as a man-in-the-middle. In addition, because BPDUs are not encrypted, it is fairly simple to intercept BPDUs in transit, revealing important topology information.

As you say, though, the tenant could do things like run OVS and accidentally create loops that STP could have prevented, though I suspect this is likely a rare case.

I'm guessing it's not possible to allow STP packets to traverse the port without interpretting them, though this would require research.

Since there are tradeoffs, one option is that HIL could expose disabling STP as a configurable, disable it by default, and let the sysadmin decide. What do folks think?

[zenhack]

I'm guessing it's not possible to allow STP packets to traverse the port without interpretting them, though this would require research.

I'd like us to do said research before implementing something else -- if it is possible, I think it would be the ideal solution.

[henn]

@zenhack - I don't think this is going to be possible, since if the switch were able to pass along STP frames, it would need to pass it along its backbone links, which would be trusted links that would cause the fabric to interpret them.

That being said, it'd be a fun little project for someone to capture an STP packet, then replay it on a port that has STP disabled and see if it shows up at the uplink.

[zenhack]

Ok, if it's not possible then we'll have to disable it. We should of course document that it won't work.