2

Consider the following topology:

Network Topology

This image was copied from here and in this article it specifies the following:

Remember that port Fa0/24 on SW2 is an untrusted port from DHCP Snooping’s point of view, so it drops the packets by default because Option 82 exists. That traffic never makes it to DWS1.

Okay, this is expected due to Option 82, and we only have ports Fa0/11 and Fa0/2 as trusted, but it presents two fixes for this issue:

SW2(config)#ip dhcp snooping information option allow-untrusted

and

An alternative would be to make port Fa0/24 a trusted port, but this would expose us security-wise.

The article does not describe why setting the interface Fa0/24 as a trusted port is a security issue. Nor it explains what's the implications of allow-untrusted option in DHCP snooping information (Option 82).

Improve this question

2 Answers 2

Reset to default
3

Trusted ports lead to DHCP servers. On SW2, that's Fa0/11. On SW1, that's Fa0/2. Those are the only ports on which one expects DHCP replies. Trusting any other ports potentially allows DHCP servers to exist where they shouldn't. In this case, setting SW2 Fa0/24 to trusted most likely wouldn't be an issue -- because it's in inter-switch link, but it is not the proper solution to the issue. (option 82 is the issue, so focus on a solution limited to option 82.)

Improve this answer
3
  • Hi Ricky, I'm aware of this. But the question was about the difference between enabling allow-untrusted vs adding Fa0/24 as trusted. I want to understand what happens when allow-untrusted is enabled and what are the security implication of this. Thanks!
    – Vinícius Ferrão
    Commented Jun 24, 2020 at 3:54
  • As I've said, setting a port to "trusted" when there should not be DHCP servers on it is a potential security problem. "allow-untrusted" simply turns off the (IMO) broken behavior that's dropping requests with the option already set. The implication is that end-users may set option 82 to whatever they like to subvert whatever process(es) one might have in the DHCP server. What you are trying to accomplish with that configuration is to "trust option 82 on this port"; on edge ports, you still want the request dropped.
    – Ricky
    Commented Jun 24, 2020 at 6:46
  • Ok! I'm still not 100% satisfied, but I made the changes in production and it worked. It's nice to see that snooping table isn't broken after the changes. Thank you! PS: I agree with broken behavior.
    – Vinícius Ferrão
    Commented Jun 27, 2020 at 23:43
1

DHCP snooping filters server-side traffic (offer, acknowledge) from untrusted ports or IP addresses (depending on configuration). It doesn't filter client-side traffic (discover, request). So, configuring Fa0/24 as trusted isn't required and doesn't make sense.

As Ricky has pointed out, wouldn't be a security issue though since Fa0/24 leads to a switch that also implements DHCP snooping.

Note that for DHCP snooping to be effective it needs to be present on all (access) switches that have untrusted ports. Activating it on the distribution or the core levels isn't necessary. (But it reduces the impact of a DHCP attack when an access switch isn't configured correctly.)

Improve this answer
2
  • Yes, but about the questions: what are the security implications? allow-untrusted does not seems to something OK. What happens exactly?
    – Vinícius Ferrão
    Commented Jun 24, 2020 at 3:55
  • As stated, it is not a security problem in the described scenario.
    – Zac67 ♦
    Commented Jun 24, 2020 at 6:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.