Dynamic Trunk Protocol: Wireshark research.

Time to review something that has been very unclear to me from the beginning: Dynamic Trunking Protocol. First off, it’s a Cisco-only protocol, and let’s be honest, it has no real world uses except acting as a security risk. Second: most literature about it is in fact quite unclear, except the CCIE OCG so far, but even then I’m left with question marks.

So let’s go through the theory first, as this is usually the best way to start:

• DTP sends special frames out of every switchport by default, which can be used to negotiate a trunk link, and negotiate the encapsulation (802.1q or Cisco-proprietary ISL).
• The frames can either be ‘auto’, ‘desirable’, or ‘on’. While ‘desirable’ and ‘on’ actively try to negotiate a trunk, ‘auto’ only negotiates one when the other end is set to trunking.
• The ‘switchport nonegotiate’ command prevents DTP frames from being sent.

Now, let’s see how it goes in practice.

Commands without effect
It’s never mentioned explicitly in any literature I’ve encountered so far, so I tested it just to be sure. The commands ‘switchport access vlan number‘ and ‘switchport trunk allowed vlan numbers‘ do not have any effect on DTP at all. Should the port become an access port, then the ‘switchport access’ command is used to define the VLAN, and the trunk allowed list is ignored. Should the port become a trunk, the trunk allowed list is used and the access VLAN is ignored. Same for ‘switchport trunk native vlan number‘, which is only used should the port become a trunk.

Default configuration
The default configuration of a Cisco switch is to send out DTP auto frames. This means no trunk link will be formed unless configured to do so. And here’s the security risk: if you leave a port in it’s default configuration, someone sending a DTP desirable frame can form a trunk and gain access to all VLANs. In case you’re thinking ‘Oh, this is highly theoretical’: it took me less than 30 minutes to find, download and install Yersinia on a Linux VM and send DTP frames to my home lab switch.

Commands with effect, and their changes
So what actually influences DTP? Two commands, it seems: ‘switchport mode’, and ‘switchport nonegotiate’. I’m listing my findings below, after trying all possible combinations on a switch:

• Default configuration: DTP sends two frames every 30 seconds (a timer that can’t be changed): one untagged frame, one ISL encapsulated frame. Both are DTP ‘auto’ mode (status code 0x03). Since ISL has no concept of native VLAN and some (older) switches only support ISL, sending the second ISL frame makes sense for compatibility reasons. DTP also sends a DTP Type, which is a HEX code listing the supported encapsulation methods.
• ‘switchport mode access’: no DTP frames are sent. At all. The ‘switchport nonegotiate’ does not make any difference.
• ‘switchport mode trunk’: DTP frames are sent in mode ‘on’, with a status code of 0x81. Since you have to choose either ISL or 802.1q as an encapsulation method before you can make the port a trunk, DTP sends this parameter too: 0xa5 for 802.1q and 0x42 for ISL. Also, independent of the encapsulation chosen, DTP will again send two frames: one untagged, one ISL encapsulated.
  Note that this port will operate in trunk mode regardless of what the other end decides. The frames are sent to help the other end in negotiation and choosing the right encapsulation. A port with default configuration will convert to a trunk port when receiving these DTP frames.
  Using ‘switchport nonegotiate’ here stops the sending of DTP frames. Should this port connect to a port with default configuration now, it will still be a trunk, but the other and will stay an access port.
• ‘switchport mode dynamic auto’: this is the default configuration and this line will not even show in the running config.
• ‘switchport mode dynamic desirable’: again like the default configuration, the only difference being status code 0x04, and a trunk will actively form when a port running DTP is connected (no matter the other end’s DTP mode).

Another unexpected command which has effect is the ‘vtp domain name‘: I’ve researched that before.

Practical implications
So what’s best in practice to counter any unexpected behavior, and security risks?
In case of an access port, ‘switchport mode access’ is effective enough as it shuts down DTP on a port. ‘switchport nonegotiate’ is a redundant command, so it doesn’t matter whether it’s applied or not. Just defining ‘switchport access vlan number‘ without the matching ‘switchport mode access’ is a security risk.
In case of a trunk port, I would still recommend disabling DTP, so a static configuration with ‘switchport nonegotiate’ becomes mandatory.
And what if DTP somehow is required to run, can the risk be minimized? (This is theory, if someone requires DTP, you… try to stay calm.) Yes: ‘switchport trunk allowed vlan numbers‘ can be configured to only allow access to the default access VLAN, or even set to ‘none’. This command doesn’t become effective until a trunk is negotiated.
Last, the Nexus series doesn’t run DTP at all, which I personally regard as a huge plus.

So that’s my in-dept research. Probably nothing I will really need in real life, but good to know for the security consequences, as well as some more knowledge for the next certification.

Advertisement

Broadcast pings: do they work?

I’ve often seen discussions of ‘how to find devices in the network using pings’. A ping sweep is easiest, but some people claim that a simple ping to the subnet broadcast address will make all devices respond. I decided to test this out for myself and see what happened.

I created a subnet with as many different devices as I could get my hand on at the time. The devices were the following:
– Windows 7 physical machine
– Windows XP physical machine
– Windows Server 2008 R2 virtual machine
– Fedora 15 virtual machine
– Vyatta 6.1 virtual machine
– Cisco 2611 router
– Cisco VG200 Voice Gateway
– Two Cisco 3560 Layer 3 switches
– A Linksys router with DD-WRT firmware
– The ISP-provided gateway: a Motorola with NAT
– Cisco 7912 IP Phone
– And finally, one iPod, for a total of 12 devices having an IP address.

I ran Wireshark on the physical machines (Windows 7 and Windows XP) from which I was going to originate the pings. I also did pings from some of the Cisco devices. Contrary to Windows, IOS will list all replies received when sending to a broadcast address. All devices received an IP address in the 192.168.0.0/24 range, the pings were done to 192.168.0.255.

I did several tests and also changed IP addresses several times between tests to ensure ARPs were sent around the network, which made it easier to follow the captures on Wireshark. The results showed a clear separation between network devices and end devices: the Cisco gear (with the exception of the IP Phone) would respond to broadcast pings, as well as the DD-WRT. All other devices wouldn’t respond to broadcast pings. The Vyatta and the ISP gateway are also network devices, but I have no control over the gateway, and the Vyatta is actually nothing more than a stripped-down Linux and thus may react as an end device in this regard. To be sure I didn’t make a mistake, I did unicast pings after this to the addresses that didn’t respond, and they all reacted fine. No firewall issues here.

There’s still a difference between a ping sweep and a broadcast ping, even if just done towards network devices: a ping sweep will trigger ARP requests for each address, to which devices will respond if they have the address, whether ICMP pings are blocked or not. So after a ping sweep, just doing ‘arp -a’ in the Windows command line reveals all managed network devices.

That answers one question, but what about IPv6? Are things different there? A ping sweep is nearly impossible. A common /64 subnet is 1.8×10^19 addresses, with EUI-64 (see a perfect explanation about EUI-64 on Packetlife.net) you can exclude some addresses, leaving ‘just’ 2.8×10^14 possible combinations. Multicast pings would be the only feasible option to scan a subnet. Note that I say multicast, as IPv6 has no concept of broadcast. Since most of my devices do not have IPv6 support for the moment (I’m planning on upgrading them in the future), I’m left with the Vyatta, Windows 7, Windows Server, and Fedora for this test. But the test results are similar to IPv4: a ping to FF02::1 (‘all nodes’ multicast) does not give a single reply, but a ping to FF02::2 (‘all routers’ multicast) gives a reply from the Vyatta, which is indeed configured for IPv6 routing. So with limited testing I can conclude for now that it’s also just network devices that respond to ping in IPv6.

To return to the original claim that a broadcast ping will reveal all devices in a given subnet: the conclusion is that this only goes for network devices, and not for end devices. It’s probably not an effective way to quickly map a subnet in everyday life.

Layer 2 device discovery methods.

Readers pursuing a CCNA (or higher) certification are most likely familiar with CDP: Cisco Discovery Protocol. CDP runs directly on layer 2 (without the use of IP addresses) in the network and will map neighbouring devices.

CDP works great on a Cisco-only network to find out the network topology, and makes negotiating links with Cisco IP Phones easy. Despite the name, it was never made proprietary. As such, tools exists for Linux (and if you insist on trying it, here‘s a nice guide) and several of Cisco’s competitors have IP Phones supporting CDP.

There are a lot of other vendor-implementations of the protocol, for example Extreme Discovery Protocol by Extreme Networks (of which I found something on the Wireshark wiki), but in a multi-vendor environment, the best solution is LLDP (802.1ab): Link-Layer Discovery Protocol, the vendor-neutral device discovery protocol. Cisco switches have CDP enabled by default, and LLDP disabled, but it is present. The commands for both are very similar:

Switch(config)#cdp run
Switch(config)#exit
Switch#show cdp neighbors

Switch(config)#lldp run
Switch(config)#exit
Switch#show lldp neighbors

Naturally for LLDP there are also some Linux deamons, a list of which can be found here (thanks to Wikipedia for the link). But what about Windows? That seems to be a different story: while software does exist, it’s quite simple and a full version is not free. For CDP, the best thing to use is Tallsoft’s CDP client. The free version gives the company’s website as the device name in CDP, but it’s the only version of CDP software I got to work on Windows.

For LLDP, the only software I got to work eventually was the haneWIN LLDP client. It’s a 30 day trial but works nicely, as illustrated below.

Note that I’m connected by Ethernet here, not wireless. Though my wireless gateway did forward CDP frames (as do all CDP unaware devices), it did not do so for LLDP frames, despite not advertising LLDP itself. Since the wireless gateway is provided by my ISP, I have no further control over it.

Finally, there’s one more protocol that’s commonly used to map devices on layer 2: LLTD or Link Layer Topology Discovery, a Windows proprietary protocol. It’s activated by default on Windows Vista and Windows 7, and it’s responsible for giving the visual representation in the Windows Network & Sharing Center in the Control Panel. But since it’s only available on those two Windows versions, the image will not display any Linux or Apple computers, as well as older Windows version like Windows XP. Also, it has no idea how the rest of the network looks like, so it makes assumptions based on what it believes the network should normally look like. In my case, my 3560 switch is nowhere to be found, but another switch is listed connected to a wireless access point, which is not there (though I suspect it is simply a separate representation of the build-in switchports in my wireless gateway).

So conclusion: a layer 2 device discovery protocol that works on all devices exist. I was able to get CDP running on all devices, but LLDP is a better choice given the broader support in network devices. Not surprising since this is why LLDP was created. What is surprising though, is the generally poor support for these protocols in Windows. Just one piece of software per protocol, a small monopolistic market. It seems like there never was a need for large-scale deployments of these protocols, so the market never fully developed.