Adam,

AdamBudzinski · ‎01-27-2016

Hello all,

quoting from CISCO Networking Academy:

" - Trusted ports can send DHCP requests and acknowledgments.
- Untrusted ports can forward only DHCP requests."

Just to verify with you guys.

By saying "requests" they refear to DISCOVER, REQUEST, INFORM, DECLINE, RELEASE (so originating from a DHCP client).

And while saying "acknowledgements" they refear to OFFER, ACK , NAK (originating from the DHCP Server).

Correct ?

Thank you in advance !

BR

Adam

SAM R. · ‎01-27-2016

Adam,

When a switch receives a packet on an untrusted interface and the interface belongs to a VLAN in which DHCP snooping is enabled, the switch compares the source MAC address and the DHCP client hardware address. If the addresses match (the default), the switch forwards the packet. If the addresses do not match, the switch drops the packet.

The switch drops a DHCP packet when one of these situations occurs:

•A packet from a DHCP server, such as a DHCPOFFER, DHCPACK, DHCPNAK, or DHCPLEASEQUERY packet, is received from outside the network or firewall.

•A packet is received on an untrusted interface, and the source MAC address and the DHCP client hardware address do not match.

•The switch receives a DHCPRELEASE or DHCPDECLINE broadcast message that has a MAC address in the DHCP snooping binding database, but the interface information in the binding database does not match the interface on which the message was received.

•A DHCP relay agent forwards a DHCP packet that includes a relay-agent IP address that is not 0.0.0.0, or the relay agent forwards a packet that includes option-82 information to an untrusted port.

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-2_52_se/configuration/guide/3750scg/swdhcp82.html#wp1058138

Peter Paluch · ‎01-27-2016

Hi Adam,

DHCP Snooping performs a large set of verifications, and accepting certain types of messages on certain types of ports is only a subset of what it does. Knowing that you can handle the hard truth ;) I am going into details :)

DHCP Snooping indeed understands the concept of a trusted and an untrusted port. Whenever a DHCP message arrives to a switch (sourced either by a client or a server), DHCP Snooping performs the following checks:

If a DHCP server message is received on an untrusted port (OFFER, ACK, NAK, LEASEQUERY), it is dropped.

This prevents unauthorized DHCP servers from sending packets into the network.

If a DHCP client message (DISCOVER, REQUEST, DECLINE, INFORM, RELEASE) is received on an untrusted port and the source MAC address of the frame does not match the chaddr (client hardware address) field inside the message body, it is dropped.

This prevents a client from sending messages claiming a different MAC address than the one truly owned by the client.

If a DHCP RELEASE or DECLINE message is received on an untrusted port but the information about the client (its MAC address, IP address, VLAN, port) are recorded in the DHCP Snooping binding database for a different port, the message is dropped.

This prevents a client from impersonating another client and telling the DHCP server that the IP address of the other client is either being returned (RELEASE) or that it is already assigned and in conflict (DECLINE).

If a DHCP message containing a non-zero relay agent IP address is received on an untrusted port, it is dropped.

This prevents a client from impersonating a router with DHCP Relay and requesting an address for a client possibly in a different network.

If a DHCP message containing a DHCP Option-82 is received on an untrusted port, it is dropped.

This prevents a client from attaching specific information into the message that would potentially influence the IP address and other configuration assigned from the server.

If the packet has passed all these checks and was not dropped, the switch will forward it depending on what type of packet it is. If it is a client packet, it can be forwarded out only through trusted ports. This makes sure that other clients (and possibly rogue DHCP servers) cannot eavesdrop on someone else's communication with DHCP, even if it is done through broadcasting. If it is a server packet and was received on a trusted port, it will be forwarded back only toward the client for which it is intended, even if the destination MAC is a broadcast - this, again, helps prevent other clients from seeing the DHCP communication of other hosts with the DHCP server.

Feel welcome to ask further!

Best regards,
Peter

AdamBudzinski · ‎01-28-2016

Thank you Peter and Samuel,

Please apologize for the late response.

Considering the scenario:

Any host being attached to a untrusted port will be able to send DHCP client messages IN (packet from Host A on FA 0/1) the attached port but the packets will NOT reach hosts that are attached to the switch on untrusted ports (for example Host B ), even if the packet is a broadcast. Correct?

BUT if let’s assume PC2 (a very unhappy co-worker at office) is connected to FA 0/3 which is a untrusted port, it would still be able to obtain IP configuration from the DHCP Server. So I guess, one of the options to secure this port would be to “shutdown”

It right ?

And also, is the configuration of DHCP snooping let’s say always implemented in terms of best practice ? Or at least should it be ?

Appreciate any thoughts !

BR

Adam

Peter Paluch · ‎02-02-2016

Hi Adam,

I am sorry for this late response.

Any host being attached to a untrusted port will be able to send DHCP client messages IN (packet from Host A on FA 0/1) the attached port but the packets will NOT reach hosts that are attached to the switch on untrusted ports (for example Host B ), even if the packet is a broadcast. Correct?

Correct. DHCP client messages received on untrusted ports are not leaked out other untrusted ports, even if they are broadcast.

BUT if let’s assume PC2 (a very unhappy co-worker at office) is connected to FA 0/3 which is a untrusted port, it would still be able to obtain IP configuration from the DHCP Server. So I guess, one of the options to secure this port would be to “shutdown”

PC2 would indeed be able to obtain its IP configuration from the DHCP server. The DHCP Snooping mechanism is not supposed to prevent clients from getting their own configuration from a DHCP server. DHCP Snooping tries to prevent malicious users

from eavesdropping on other hosts' communication with DHCP
from impersonating a DHCP server
from spoofing their identity by sending messages using some other host's MAC address
from using illegal options in messages that could result in these clients receiving inappropriate and unintended configuration

If you wanted to prevent an attached host from obtaining its configuration via DHCP, you would need to either block the DHCP communication entirely using an ACL, or perhaps deploy 802.1X authentication, making sure that unauthenticated clients are put into a VLAN without DHCP service.

And also, is the configuration of DHCP snooping let’s say always implemented in terms of best practice ? Or at least should it be ?

I would personally say that the DHCP Snooping is an important security measure that should be deployed on access layer switches if possible. Today's networks heavily depend on DHCP, and malicious - or even careless users can wreak havoc with their network by posing as DHCP servers themselves.

Best regards,
Peter

dipesh shah · ‎07-21-2016

Guys, I have a scenario to configure DHCP snooping. just wants to know how the configuration will be deployed in scenario 2.

Scenario 1:

Access switch(L2) connected to core(L3 gateways for all vlan) and then DHCP server connected to core. for this scenario following configuration will be good to go:

########################################

##Access switch DHCP Snooping configuration ##

########################################

ip dhcp snooping
ip dhcp snooping vlan x,y,z
!
interface range gi1/0/1-46, gi2/0/1-46
description *** Access Ports connected to PC***
ip dhcp snooping limit rate 200
!
interface range te1/1/1-4, te2/1/1-4
description *** Uplinks connected to CORE switch***
ip dhcp snooping trust
!

###########################

##Core switch DHCP snooping ##

###########################

ip dhcp snooping
ip dhcp snooping information option allow-untrusted
ip dhcp relay information trust-all
ip dhcp snooping vlan x,y,z

int Port-channel33
descriprion *** port facing towards DHCP server ***
ip dhcp snooping trust
!

Scenario 2:

Access switch(L2) connected to core (L2), Core switch connected to PaloAlto firewall(L3 gateways for all vlan) and then DHCP server connected to core.

so in this scenario i wants to check how the dhcp snooping configuration we are gonna do.

will it be same like scenario 1 or we need to do any changes here ?

thanks in advance. your help would be much appreciated.

Dipesh.

Peter Paluch · ‎07-22-2016

Hi Dipesh,

Regarding Scenario 1, once you have deployed DHCP Snooping on your access switch, it does not make sense to run it again on your core switch. If there are no DHCP clients connected to your core switch, I suggest you remove all DHCP Snooping configuration from your core switch altogether. Keep in mind that once the DHCP messages have been sanitized on the access switch, you are not getting any added security by performing the same checks again on the core switch.

With this in mind, I would say that the second scenario looks, as far as DHCP Snooping is concerned, pretty much the same. DHCP Snooping should only be run on the access switch. Running it deeper in the topology (on distribution layer switches or on core switches) makes no sense.

What do you think?

Best regards,
Peter

dipesh shah · ‎07-24-2016

HI Peter,

Thank you very much for your input, it makes more sense. so now just last doubt I have in mind is that Dynamic ARP Inspection will be configured on Access switches only, right ?

Regards,

Dipesh.

Peter Paluch · ‎07-26-2016

Hi Dipesh,

Yes, you're absolutely right - the Dynamic ARP Inspection will also be configured on access switches only. It does not make sense to run it on distribution or core layer switches.

Best regards,
Peter