Yes but if MLS gets blocked at layer 2, because of root guard, layer 3 wont work as well. That was my point
So the only thing I can think of this maybe useful in case of trunk ports, is if there was some network based unauthorized access to a non root bridge, which remotely configured to become a root brdige.
Then the real root brdige will block its designated ports, and if assuming it is connected to a router, through which all external traffic goes, the switch will block all traffic and prevent access, causing just temporary DOS.
In case of physical access, nothing can help of course. But even in case of network access, just hard to imagine how to bypass firewall, access list, and authentication, that require to do this.
So only access ports, most logical still.
My previous response was in relation with the Root Guard, because you seemed not considering this as a good security technique, so I wanted to demonstrate you that in described scenario was actually the only one possible.
Also the premisse was the fact of a physical access (remotely is possible but rather from inside the network segment).
The whole idea with the Root Guard - at least this is what CISCO writes on the web - is "to secure root bridge location inside the STP domain". Going further with this, it might be obvious why you can't use BPDU Guard on trunk ports so the question remains - what should you use, in order to be able to prevent L2 loops and in the mean-time, not to allow a root re-election - which in case of a compromised switch, can render traffic to go through it and this way making an attacker to be able to sniff traffic which was not supposed to flow through this switch.
In case of a remote attack, I am not sure why would you make that router link a STP one - routers are separating broadcast domains so they will no longer use the L2 between their interfaces, making it impossible to create L2 loops.
Router just allows routing - gateway to the internet, where I assume the network based unauthorized access came from. The router is probably connected to the core switch, and core switch is the root bridge.
(I didn't really study design, but I guess how it would be)
The unauthorized access traffic goes through router => core switch => one of the non root bridge switches that got compromised.
It's getting reconfigured with lower priority, and trying to become new root bridge, to make all traffic go through it.
The real root bridge sense superior BPDU on one of the root guarded designated ports, and start dropping frames, cutting the connection to the router and the internet, where the attack came from.
The function of root guard is so simple: Put ports into listening state, that trying to become anything else than designated port. (root bridge have all ports desg)
It doesn't force anything. It just blocks.
So all you can do with root guard inside STP domain is setup bunch of block triggers, that will cause mess, and maybe DOS, in case of re-election.
Unless you enable it on specificly chosen ports, like your first example with campus again.
I guess the good practice to enable it on: A port to a less secure remote location, within the same STP domain.
So if one of the switches compromised on that remote location, and start sending superior BPDU to the main location, the ports will go to listenig mode, and ignore everything.
Of course to secure your main location internal STP domain, you need proper physical and L3 security.... and BPDU guard on edges.
Look - I know exactly what routers are doing
What you are not aware is that in case of Root Guard only the port which receives superior BPDUs will enter on root-inconsistent state thus not generating a topology change and all other DP will remain in forwarding state. The router in this case is upstream so the link to it is not going to be affected, nor will be affected all other DPs - that was my point. So all you get blocked is the trunk to the bridge where the superior bpdu is coming. The DDOS will be on the downstream to the corrupted bridge. This is why, you should consider root guarding all the DPs from the STP domain, if you are looking to conserve the root bridge position.
And to bring the discussion to the starting point - where you said that the difference is for "choosing a more restrictive approach" and "special situations" I am wondering how are you going to use BPDU Gurad on TRUNKS!
The example we are talking about - and in which it seems we are focusing on other matters like routers and if this could be an external attack - is just another situation of using ROOT GUARD instead of BPDU GUARD.
And to have a complete picture - just imagine using all the time ROOT Guard on trunks combined with BPDU Guard on access ports, unless there is a specific situation where you have to use ROOT Guard on acccess p.
In any case, to be honest, what I am using while conducting such kind of attacks is a linux box and not a bridge - lol - but as this is a CISCO forum, I am not going to speak about linux here. I doubt an internal user will ever carry a bridge with him to do such a things - but of course this is not going to cover the situation of a physical breakin or an outside attack against a switch.
Ok here's some crazy diagram image I found in google for reference
Lets say D5 is the root bridge, and it has all its designated ports - root guard enabled.
Attacker theoreticlly somehow bypass router firewall from outside, and able to gain access to A7.
Configures it with 0 priority, and it sending lower BID to the segment.
D5 will recieve these bpdu eventually on all ports, because other switches also forward these bpdu, and all the root guard enabled ports on D5 will go into listening mode, keeping the root brdige status.
A7 will also remain root brdige as well, and all other switches will accept it as the new root bridge, because of lower BID, even though D5 still root as well, and still sending bpdus probably, with higher BID.
So D5 ignore everyone, and everyone ignore D5.
If there was only one core, the connection to the router, or MLS, will be cut, so no routing as well, and if attacker came from outside, it would also disconnect.
In this case (with redundant connection to the router) it could come from outside or inside, and nothing will stop it, using computer logic at least. Maybe IPS would help, no idea
BTW if you enable root guard on other switches, it will be a mess if root bridge goes down. Everything will be blocked.
It's only useful to enable on ports that connect to a switches in remote, less secured, location, regardless if ts access or trunk. This allow normal traffic between locations, but if a switch is compromised on the remote location, trying to become new root, they get cut off, and no traffic will pass.
Also I didn't say you can use bpdu guard on trunk ports. It make no sense. Access edge type only.
Mate - this is my last reply - I think this discussion has degenerated in a race of who is right and who is not and I am not keen to proof I am right, I just want to show some situations where you should use this feature - if you want to listen, ok, if not, your choice.
In your diagram and 'exempli gratia' if A7 will become the corrupted bridge it will start flood superior BPDUs to D5 and D01 - as these are the only links it has. This will put the Distribution Switches ports in root-inconsistent state isolating the A7. They are not going to forward the BPDUs received from A7 so all the others switches will remain in the same state with D5 being the root for the STP domain. So where is your "total blocking mess" coming from?
More than this - BPDU ROOT Guard is making a port transition to root-inconsistent state ONLY if the received BPDU is superior. Now, considering that your ROOT bridge in the STP should have the best BPDU ID to be root, a secondary ROOT which is going to take place in case of root bridge fails, will have the second lowest value so the root guarded ports will not receive a superior BPDU of the initial value but one with a lower value.
You can find an example in a CISCO Press book which shows you how to enable the BPDU ROOT Guard on trunks and why, here: http://www.informit.com/library/content.aspx?b=CCNP_Studies_Switching&seqNum=35
Yes - if you are crazy enough to cut your external connection you will start flooding in a dumb manner, all the links - but this is not going to happen in real life because someone with such skills to compromised a switch remotely is not a retard - and this is why I have used the physical approach where someone will just plug into your switch directly and also I have told you about the Linux box and an internal attack, because are more probable than some remote connection via Internet to an Access Switch.
If you have by chance 4 switches you can try in practice this example and see what is going to happen. Best to have CISCO but you can use it with other vendors as well (not going to advertise here as it is not ethical)
So - again - as the best practice, use BPDU Guard on all access ports unless there is a special situation (like the attached network one) where you shoud use ROOT Guard only on that port or few ports and BPDU ROOT Guard on trunks in your domain, to preserve your ROOT Bridge position.
No no, don't give up, its getting closer and clearer to my point. There's some detail, either you forget, or I'm not aware of. I'll bring that image again:
You say that if A7 is cracked or replaced, it will be blocked from the STP domain. I agree it will blocked on link A7-D5 link, if you enable root guard on D5 for that port, but A7-D01 will still forward traffic and bpdu to everyone else.
And everyone, except D5, will think that A7 is the new root bridge.
So the only switch that gets isolated is the old root bridge: D5.
Now you probably thinking: Let's enable root guard on D01? But you can't.
Why? Becuse one of it's ports must be root port, which connected to one of the access switches. You can't enable root guard on root port of course. Only on designated.
You can enable it on 2/3 of the ports, that are designated ports, but then there's 33% that it will happen on a switch that connected to the non protected port.
Though there's a workaround: I don't know why it's not shown in this design, but you can make another redundant link between the two cores: D5-D01
Then the 4th port of D01 on that segment will become the root port, and all other 3 ports will always be designated, and then you can freely enable root guard on these lower 3 ports of D01 in the picture, and it will work the way you described.
Phew - you are really funny - I must admit I didn't see there is no link between Distros
1) My advise - never implement this topology in a production env
2) I will consider D5 root bridge for all Vlans - not a per vlan implementation where one can split between the 2 Distrib. Also - very important, MLS trunks will be switchports not router ones - because with the last ones we shouldn't bother with this discussion
3) I will consider the case where the D01 port facing to A7 is a Root port
4) All D5 are DPs - segment A7 -->D01 will be up connecting to the router and further to the Internet - so attacker will still have a wire, even if in the beginning both A7 links were up (the D5 one became blocked due to ROOT Guard) and also stations connecting to A7 will be able to reach the router in your figure.
5) If A7 -->D01 is on FWD state, the other 2 ports on D01 will be in ALT with both root ports - making S01 and S02 ports DP where the Root Guard will block them. What result from here? Links S01 -->D5 will remain in FWD with S01 not changing the Root Bridge, and S02 ----> D5 will also keep its FWD state with S02 not changing the Root Bridge. D5 will not change the root bridge. D01 will change the root bridge indeed.
Open communications in this case? S02 nodes to S01 nodes and vice-versa; S02 and S01 nodes to the router; already mentioned nodes from A7 to the router
Closed communications - any inbound-outbound from S01 and S02 to the A7 nodes - which is good considering that switch is under attacker's control
Don't try to calculate the situation where the compromised switch will be other than A7 - just the pairs will be changed. In any case your network will remain functional in most of its parts and more than this - one of the attacked switch link will be up
And NO - I was not thinking to enable the root guard on that port.
Ok took me time to proccess your text, and now I understand your point, and I agree it's true, but it's nonsense
Why would you do it like that? Enable root guard on S01 and S02?
What if D5 just fails, and D01 set as secondary root? The point of redundency is failed, all network is blocked.
All was achieved is isolation of A7, if its misconfigured.
"Don't try to calculate the situation where the compromised switch will be other than A7"
That's the point, to see when would you use root guard in real netowrk, not just proof that it's working in such veeery specific situation.
But for this topology to work, you can't enable root guard on the current p2p ports.
The only case is if you got direct link between D5 and D01. This will keep network redundant and more secure.
I have told you not to calculate the situation where the compromised switch will be other from one simple reason - IT WILL RENDER THE SAME RESULTS. Why? simple - you have the same number of links and ports. Einstein was saying that "A mad is someone who enters the same data in an equation and expects to obtain different results each time" - so its up to you if you want to be "mad", I don't
There are 2 things you have to consider:
1) Network design should offer reliability and security - and in this case what you have found with this figure will not meet the criteria. It is true that you came up with this in the end
2) Weather you will consider a high availability approach to be more important than a security one and how much you are ready to cut from each other. If you want the highest levels, again this is not going to cover you (and there are more issues here than the ROOT Guard)
I have to admit there is an example where Root Guard on trunks will cause troubles if the root bridge is going down but this is not making ROOT Guard a nonsense and its use on trunks in a mature design, of course from one case to the other. And more than this - is not going to stop me require its implementation on trunks
Sorry to dig this up, but I was working on testing this, and I think the reason you don't want to have this on trunks is to allow switches to converge when there are link outages. Have this configured on switch uplinks can, and did during my testing, result in switches being isolated.
According to my testing, and the CCNP SWITCH book I have states that current design best practice is to place this on access ports.
Np - but please, did you read the entire post from A-Z?
If you enable ROOT Guard instead of BPDU Guard, this will not help you overcome a loop introduced in your network, from a switch with inferior BPDUs (imagine a loop made within your own infrastructure created by connecting 2 cubbicles UTP sockets each other, etc). To overcome this you will have to use BPDU Guard on your Access ports and if you are doing this, the ROOT Guard will be useless if configured on the same ports.
On the other hand, how are you going to secure the ROOT Bridge position into your network? because BPDU Guard can't be put on Trunks.
This is why, in my opinion (and please note I am probably not the first one stating this, for sure) Root Guard and BPDU Guard are 2 features designed for different functionalities (on my first post, I think, it was the classical example of some other network(s) attached to your own backbone, networks you are not administering but which are participating in STP) and which can be used together in order to achieve a more security inside your network.
The only question remaining is, how far would you like to go to secure your network and whether you can sacrifice usability (some switches isolations) for sake of security (not having your traffic flow going through some rogue device where a lot of MITM attacks can make you troubles).I suspect the CCNP Switch is oriented to usability and dynamic while Security Curricula is oriented on the security side of business.
Do you just like to argue? I'm not really going into a holistic discussion of the see-saw of security vs. useability. I'm simply stating that it's not a good idea to place Root Guard on inter-switch links and providing the reason why.
Thank you for answering a question I did have though, and that is what the use case is for Root Guard. I see how this would be applicable in a situation where you have a separate network participating in STP that you want to keep from hijacking the root bridge.
I am wondering what bothered you in the first place, something you are not willing to accept or the fact that you need to have all the time the last word on a topic (what you have stated was already said by Gregos in this case)
I have done pen testing in the last 7 years and it was not one time when I was able to crack an Access switch and start a STP ROOT Bridge attack.The attack was succesful and until the time they have discovered there was a topology change I have gathered some unencrypted info was not supposed to come in an "outsider hand". I don't know if my reports lead to some admin loosing his/her job.
Try practice more and you might figured out on what specific trunks will the Root Guard enhance your infrastructure security without affecting availability.
It is neither Raynm3n. It's your method of delivery of your opinion. You come off rather abrasive and matter-of-fact when what you are stating, I think, is truelly an opinion, and not fact. You also have on multiple occasions made offensive statements when none have been made toward you except asking if you like to argue. It's unprofessional.
Anyway, in my environment (Department of Defense), physical security is pretty tight. Your only method of entry would be at an access port. If I have Root Guard and BPDU Guard on access ports, your "STP ROOT Bridge attack" would be immediately mitigated. Not only that, if you tried to move to different access ports, I could tell where you were trying to perform the attack from as that specific access port would drop into a root-inconsistent state. On TOP of that, since Root Guard triggers before BPDU Guard, once you stopped your attack, that port would resume normal functionality without me touching it.
I don't see a real reason to place Root Guard anywhere upstream except for what was already stated - a network connection to another network that I don't control that participates in the STP topology. Sure, you could plug in on one of the distros or cores, and THAT would cause a problem, but that would also indicate a problem with physical security - and if you have a problem with physical security it doesn't matter anyway because people could cut cables, etc.
The other thing is accidental misconfig, which is difficult in our environment because most configuration goes through multiple peer reviews and is templatized and documented in engineering before being handed off to the operations group.
I need to do more testing in a full-blown core-distro-access environment to see if it could be viable otherwise, or at least whiteboard it, and maybe my opinion will change, but for right now, I'm going with what Cisco says which is that current design practices are to place Root Guard on access ports.
EDIT - Also, if you tried to plug into an unused port on a core or distro, that would likely do nothing because the port should be placed into an unused VLAN as an access port, and shut down as SOP.