dhcp INFORM flooding
amindomao at gmail.com
Wed Feb 25 21:31:12 CET 2015
> If that’s what ISC DHCP is doing, I’m all for it. There’s no RFC,
which makes it a little difficult to know what’s the “right” thing to do.
carefully and found this:
> Next, the DHCPv4 server MUST determine the "reply address and port"
> according to the first of the following conditions it finds a valid
> reply address for, in order:
> 1. If the 'ciaddr' field is non-zero, the server selects its
> contents as an IPv4 address and port 68 ('DHCP client').
> 2. If the 'giaddr' field is non-zero, the server selects its
> contents as an IPv4 address and port 67 ('DHCP server').
> 3. If the IPv4 source address field is non-zero, the server selects
> its contents as an IPv4 address and port 68 ('DHCP client')
> 4. The server selects the limited broadcast address (all-ones) and
> port 68 ('DHCP client').
> At this point, the DHCPv4 server verifies that it holds configuration
> authority over the reply address (or link in case of limited
> broadcast address) it has selected to transmit the reply to. If the
> server has not been configured to hold authority over this address,
> it MUST NOT reply. It SHOULD increment a counter visible to the
> operator but SHOULD NOT log an error (unless a mechanism is used to
> suppress repeated log messages). See the Security section
> (Section 5) for the rationale behind this direction.
> Note very carefully that a DHCPv4 server will send replies directly
> to a DHCPv4 client by way of 'ciaddr' even if the DHCPINFORM message
> was relayed. Note that this means DHCPINFORM processing is
> intentionally broken in deployments where the client's address space
> is unreachable by the DHCPv4 server. In such cases, the server
> should probably be configured not to reply to DHCPINFORMs.
So, I think I'm right.
I don't have a working isc-dhcpd now, but in one or two days I'll find
it and test this thing.
My clients flooding FR with DHCP-Informs and I want to shut their win7's up.
More information about the Freeradius-Users