Time to go old school and actually write an article.
I was working on one of my network cleanup projects when we got into a great discussion about discovery protocols. The specific switch in question that started all this had corporate users and guest users. They did have separate VLANS and things were working fine but we were approaching this from a fine tuning and security perspective.
The security person was against having any discovery protocols enabled since their announcements are generally in clear text. He was concerned that anyone with a protocol analyzer can capture a discovery packet and quickly learn the IP address and device specifics. With the device specifics, someone can quickly figure out if there are any vulnerabilities and cause problems. He added that since some of these guest ports were to conference rooms used for training, you never know who is on the other end of that cable. I can see where he was coming from and agreed in principle that this scenario was possible.
Network technicians use discovery protocols for troubleshooting and detecting errors on their network. It also saves a ton of time compared to physically tracing cables to validate which port a user is on. Some Network devices actually rely on discovery protocols to validate VLAN, duplex and other information. The Network technician also countered that this switch had Access Control Lists preventing unauthorized access, etc...
Then Network Analyst and Security person started arguing the difference between “Possible” vs “Probable” and I can see this going nowhere or getting ugly.
Unfortunately both of them have a valid point. I thought there must be some sort of compromise and proposed having discovery protocols enabled on trusted ports or networks and disabling discovery protocols on untrusted or unknown ports or networks.
Oddly enough both groups never thought of doing both. Luckily they had equipment that I was familiar with and showed them the commands to do this. The Security Analyst wanted some proof that the discovery packets were no longer on those ports/networks. Fair enough, I put a protocol analyzer on a switch port and demonstrated that the commands do in fact work.
After 15 minutes of configuration changes, both groups were satisfied and now use this as part of their standard template moving forward.
I must commend these analysts for paying attention to the network at the packet level and raising concerns that some overlook, or don’t consider an issue.