dhcp INFORM flooding
Goog day again :) According to draft-ietf-dhc-dhcpinform-clarify-06 the reply to the DHCP Inform request should be ACK to the ciaddr if it present, even if there is a giaddr or other addr's. FR 3.0.7 is repliing to giaddr whatever I'm doing... (27) Received code 1032 Id -1241645939 from 10.133.242.246:68 to 10.133.200.150:67 length 320 (27) DHCP-Opcode = Client-Message (27) DHCP-Hardware-Type = Ethernet (27) DHCP-Hardware-Address-Length = 6 (27) DHCP-Hop-Count = 1 (27) DHCP-Transaction-Id = 3053321357 (27) DHCP-Number-of-Seconds = 768 (27) DHCP-Flags = 0 (27) DHCP-Client-IP-Address = 10.133.44.151 (27) DHCP-Your-IP-Address = 0.0.0.0 (27) DHCP-Server-IP-Address = 0.0.0.0 (27) DHCP-Gateway-IP-Address = 10.133.242.246 (27) DHCP-Client-Hardware-Address = 98:4b:e1:b5:b1:b4 (27) DHCP-Message-Type += DHCP-Inform (27) DHCP-Client-Identifier += 0x01984be1b5b1b4 (27) DHCP-Hostname += '\213\245\340\240-\217\212' (27) DHCP-Vendor-Class-Identifier += 0x4d53465420352e30 (27) DHCP-Parameter-Request-List += DHCP-Subnet-Mask (27) DHCP-Parameter-Request-List += DHCP-Domain-Name (27) DHCP-Parameter-Request-List += DHCP-Router-Address (27) DHCP-Parameter-Request-List += DHCP-Domain-Name-Server (27) DHCP-Parameter-Request-List += DHCP-NETBIOS-Name-Servers (27) DHCP-Parameter-Request-List += DHCP-NETBIOS-Node-Type (27) DHCP-Parameter-Request-List += DHCP-NETBIOS (27) DHCP-Parameter-Request-List += DHCP-Perform-Router-Discovery (27) DHCP-Parameter-Request-List += DHCP-Static-Routes (27) DHCP-Parameter-Request-List += DHCP-Classless-Static-Route (27) DHCP-Parameter-Request-List += DHCP-Site-specific-25 (27) DHCP-Parameter-Request-List += DHCP-Vendor (27) DHCP-Parameter-Request-List += DHCP-Site-specific-28 (27) DHCP-Relay-Agent-Information += 0x010600040066010b020800067072cf1c79e7 Trying sub-section dhcp DHCP-Inform {...} (27) dhcp DHCP-Inform { (27) update reply { (27) Packet-Dst-Port = 67 (27) DHCP-Message-Type = DHCP-Ack (27) EXPAND %{Packet-Dst-IP-Address} (27) --> 10.133.200.150 (27) DHCP-DHCP-Server-Identifier = 10.133.200.150 (27) DHCP-Site-specific-28 = 0x0a (27) } # update reply = noop (27) [ok] = ok (27) } # dhcp DHCP-Inform = ok (27) DHCP: Reply will be unicast to giaddr from original packet DHCP-Opcode = Server-Message DHCP-Hardware-Type = Ethernet DHCP-Hardware-Address-Length = 6 DHCP-Hop-Count = 1 DHCP-Transaction-Id = 3053321357 DHCP-Number-of-Seconds = 0 DHCP-Flags = 0 DHCP-Client-IP-Address = 10.133.44.151 DHCP-Your-IP-Address = 0.0.0.0 DHCP-Server-IP-Address = 0.0.0.0 DHCP-Gateway-IP-Address = 10.133.242.246 DHCP-Client-Hardware-Address = 98:4b:e1:b5:b1:b4 DHCP-Server-Host-Name = '' DHCP-Boot-Filename = '' DHCP-DHCP-Server-Identifier = 10.133.200.150 DHCP-Site-specific-28 = 0x0a Sending DHCP-Ack Id b5fdfc8d from 10.133.200.150:67 to 10.133.242.246:68 (27) Sent code 1029 Id -1241645939 from 10.133.200.150:67 to 10.133.242.246:68 length 300 (27) DHCP-Message-Type = DHCP-Ack (27) DHCP-DHCP-Server-Identifier = 10.133.200.150 (27) DHCP-Site-specific-28 = 0x0a (27) DHCP-Opcode = Server-Message (27) DHCP-Hardware-Type = Ethernet (27) DHCP-Hardware-Address-Length = 6 (27) DHCP-Hop-Count = 1 (27) DHCP-Transaction-Id = 3053321357 (27) DHCP-Flags = 0 (27) DHCP-Client-IP-Address = 10.133.44.151 (27) DHCP-Gateway-IP-Address = 10.133.242.246 (27) DHCP-Client-Hardware-Address = 98:4b:e1:b5:b1:b4 (27) DHCP-Relay-IP-Address = 10.133.242.246 (27) Finished request
On Feb 25, 2015, at 2:30 PM, amindomao <amindomao@gmail.com> wrote:
According to draft-ietf-dhc-dhcpinform-clarify-06 the reply to the DHCP Inform request should be ACK to the ciaddr if it present, even if there is a giaddr or other addr's. FR 3.0.7 is repliing to giaddr whatever I'm doing...
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. Alan DeKok.
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.
I've read "https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06" 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.
That's correct. The response to a relayed DHCP Inform must (if it is possible) be unicast directly to the client. *BUT* if you are using a relay with separate address spaces, this will not work (the client will not receive the reply), as explained below: 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. (see https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06) -----Message d'origine----- De : Freeradius-Users [mailto:freeradius-users-bounces+nicolas.chaigneau=capgemini.com@lists.freeradius.org] De la part de amindomao Envoyé : mercredi 25 février 2015 21:31 À : FreeRadius users mailing list Objet : Re: dhcp INFORM flooding
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.
I've read "https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06" 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
*BUT* if you are using a relay with separate address spaces, this will not work (the client will not receive the reply), as explained below:
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.
(seehttps://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06)
I understand this. My dhcp server has a full ip routing information about the network.
On Feb 25, 2015, at 3:31 PM, amindomao <amindomao@gmail.com> wrote:
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.
I've read "https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06" carefully and found this:
Yes, that’s nice. But it’s a *draft*. It’s not an RFC. For every RFC that gets published, there are probably 100 drafts that get written and ignored. So… what do the *other* DHCP servers do? If they use ciaddr, then that’s what people expect, independent of any RFC or draft. Alan DeKok.
Finally I've found the solution. Here it is: 1. added 2 lines to dictioanry.dhcp ATTRIBUTE DHCP-Option-252 252 octets VALUE DHCP-Parameter-Request-List DHCP-Option-252 252 2. tuned DHCP-Inform section dhcp DHCP-Inform { update reply { Packet-Dst-Port = 67 DHCP-Message-Type = DHCP-ACK DHCP-DHCP-Server-Identifier = "%{Packet-Dst-IP-Address}" DHCP-Option-252 = 0x0a00 } ok } This configuration made win7 to shut up. It turnes out that yesterday I forgot to add "Packet-Dst-Port = 67" ( clients get their addresses via relay ) option to DHCP-Inform section. So, the question about "https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06" does not make sense any more. FR works just like in this draft.
participants (4)
-
Alan DeKok -
amindomao -
Chaigneau, Nicolas -
Phil Mayers