Re: [Dnsmasq-discuss] Duplicate IP detection with fixed IP

2018-10-08 Thread Bernard CLABOTS
 Hi Simon,   I am definitely not a DHCP expert and I don't want either to 
become a pain. Yet...   I can read that not only the behavior is not inline 
with RFC, but it even contradicts the RFC:
"3.2 Client-server interaction - reusing a previously allocated network address 
  If a client remembers and wishes to reuse a previously allocated
   network address, a client may choose to omit some of the steps
   described in the previous section.  The timeline diagram in figure 4
   shows the timing relationships in a typical client-server interaction
   for a client reusing a previously allocated network address."

=> So My iPhone is legit.

"Servers with knowledge of the client's configuration parameters
  respond with a DHCPACK message to the client.  Servers SHOULD NOT
  check that the client's network address is already in use; the
  client may respond to ICMP Echo Request messages at this point."
=> Invalidates the fix you did in 2017:"
| commit 5ce3e76fbf89e942e8c54ef3e3389facf0d9067a |
| Author: Simon Kelley  |
| Date:   Fri Apr 28 22:14:20 2017 +0100 |
|   |
|     DHCPv4: do ICMP-ping check in all cases other that current lease. |

"=> This is a real Bug affecting the current behavior. I would really 
appreciate that you unlink the authoritative link to always breaking this 
statement:"Servers SHOULD NOT respond if their information is not  
_guaranteed_ to be accurate.  For example, a server that identifies a
  request for an expired binding that is owned by another server SHOULD
  NOT respond with a DHCPNAK unless the servers are using an explicit
  mechanism to maintain coherency among the servers."

I agree that the example exposes a philosophy similar to what you implemented, 
in the sense that being an authoritative server somehow fulfils the second part 
of the example, but the example is just an example. IMHO not having a trace of 
the lease in combination with being authoritative should/could be interpreted 
as a potential Rogue client attempting a MIM attack which is actually an 
accurate info to be used to NAK the request, or arguably not answer at all. 
Could you at least make this behavior configurable? Thanks a lot!!!

I am not sure I understand what the implications might be that you fear in 
NAK-ing the request.

Thanks a lot!

Regards,
Bernard

   

   
   ___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Duplicate IP detection with fixed IP

2018-10-05 Thread Bernard CLABOTS
Hi Simon,   Sorry to come back to this question again. You wrote:"I don't think 
it would be possible to make this hack any more safe by
doing the ping-check before re-creating the lease. The whole premise is
that the client attempting to renew is already configured, but the
server lost track of it. So doing a ping-check would expect to get a
reply from the already-configured client."

Well, actually, I see at least two ways to improve that behavior, especially 
starting from the fact that assuming that the lease dB was corrupted is weird 
and not safe:
1. ARP the IP to see if you receive any answer other than the client asking the 
IP (more efficient but fails if using proxy arp).
2. PING the IP and expect to receive an answer from that same MAC (might fail 
if device is set to not answer ping).
if not, then reject and force 4 way. Indeed, if you receive no answer, you can 
no longer assume that this is the legit owner of the IP. Anyway, if the client 
is legitimate, the algorithm will most probably give him the same IP.
The main drawback is an increased handling time, but that only occurs if the 
lease is unknown.

 

On Wednesday, 19 September 2018, 13:01, Simon Kelley 
 wrote:
 

 

On 19/09/18 11:09, Bernard CLABOTS wrote:
> Thanks a lot for this answer.
> 
> Indeed, it is a special case as we have a simple two way Request/ACK,
> this is also what is seen with some implementations when quickly
> unplugging/re-plugging the cable, it is legal AFAIK.
> 
> I also agree on the necessity to be efficient in case of loss of the
> lease dB.
> 
> Yet reading the RFC-2131, I saw:
>   If the client's request is invalid (e.g., the client has moved
>   to a new subnet), servers SHOULD respond with a DHCPNAK message to
>   the client. Servers SHOULD NOT respond if their information is not
>   guaranteed to be accurate.  For example, a server that identifies a
>   request for an expired binding that is owned by another server SHOULD
>   NOT respond with a DHCPNAK unless the servers are using an explicit
>   mechanism to maintain coherency among the servers.
> 
> **//___^Referring to the first sentence, I agree it is only a should.
> Though, the next sentence is, according to your explanation, also
> relevant in this case, so DNSMasq should not respond if the information
> is not guaranteed to be accurate. Which also means that changing the
> authoritative flag, we risk to end up in the exemplified case where
> DNSMasq cannot guarantee that the requested IP is belonging to another
> DHCP Server, so it should not NAK and we are going in circles...
> We can of course discuss whether the Request is invalid simply because
> that IP is currently used by another device while not even assigned
> through DHCP. I would argue that the DNSMasq code explicitly accept that
> requesting the IP of the server fulfills this condition, which IMHO is a
> similar case.
> **//___^
> Anyhow, moving forward to resolve the issue I face, is there any way to
> force the RFC behavior of NAK-ing and forcing the 4 way exchange?
> 

If you don't set dhcp-authoritative, then the client will eventually
move to the four-way exchange, but it may take some time, as it involves
time-outs. The reason for this is that the dnsmasq server has to assume
there are other DHCP servers on the network which may hold a lease for
the client.

The differences in behaviour are these.

Without dhcp-authoritative:

1) A client sending DHCPREQUEST in init-reboot state which doesn't have
a lease in the database will be ignored.

2) A client sending a DHCPREQUEST in rebind mode which doesn't have a
lease in the database will be ignored. In renew mode (ie unicast
request) it will get a DHCPNAK.

3) A client sending a request with the wrong server-id will be ignored.

With dhcp-authoritative

1) A client sending DHCPREQUEST in init-reboot state which doesn't have
a lease will have the lease created

2) A client sending a DHCPREQUEST in renew or rebind mode which doesn't
have a lease in the database will have a lease created.

3)  A client sending a request in INIT_REBOOT or SELECTING state with
the wrong server-id will get a DHCPNAK.


Cheers,

Simon.




   ___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Duplicate IP detection with fixed IP

2018-09-19 Thread Bernard CLABOTS
Thanks a lot for this answer.
Indeed, it is a special case as we have a simple two way Request/ACK, this is 
also what is seen with some implementations when quickly unplugging/re-plugging 
the cable, it is legal AFAIK.
I also agree on the necessity to be efficient in case of loss of the lease dB.
Yet reading the RFC-2131, I saw:  If the client's request is invalid (e.g., 
the client has moved
  to a new subnet), servers SHOULD respond with a DHCPNAK message to
  the client. Servers SHOULD NOT respond if their information is not
  guaranteed to be accurate.  For example, a server that identifies a
  request for an expired binding that is owned by another server SHOULD
  NOT respond with a DHCPNAK unless the servers are using an explicit
  mechanism to maintain coherency among the servers.

Referring to the first sentence, I agree it is only a should. Though, the next 
sentence is, according to your explanation, also relevant in this case, so 
DNSMasq should not respond if the information is not guaranteed to be accurate. 
Which also means that changing the authoritative flag, we risk to end up in the 
exemplified case where DNSMasq cannot guarantee that the requested IP is 
belonging to another DHCP Server, so it should not NAK and we are going in 
circles...We can of course discuss whether the Request is invalid simply 
because that IP is currently used by another device while not even assigned 
through DHCP. I would argue that the DNSMasq code explicitly accept that 
requesting the IP of the server fulfills this condition, which IMHO is a 
similar case.
Anyhow, moving forward to resolve the issue I face, is there any way to force 
the RFC behavior of NAK-ing and forcing the 4 way exchange?
Thanks a lot!Regards,Bernard 

On Wednesday, 19 September 2018, 1:16, Simon Kelley 
 wrote:
 

 On 18/09/18 16:59, Bernard CLABOTS wrote:
> Hi all,
>    I have been trying to replicate an issue of IP conflict on Open-WRT,
> the issue is randomly seen, and I expect in real life, it is related to
> a de-sync of the lease data base with the actual situation (in case a
> switch is between the client and the server and the server is rebooted
> e.g., so that the client acts as though it would have a fixed IP.
> Reported as seen as well when moving a client from one setup to another
> setup where the IP that it used to receive is used on the LAN).
> 
>    I tested with 2 different versions of dnsmasq (2.78 and 2.79).
> 
>    I use Scapy to forge DHCP Requests (see further).
> 
> Setup:
> I have a laptop with a fixed IP inside the range of the DHCP
> (192.168.1.0/26). I then forge a Request of that IP using scapy and I
> cannot explain the behavior:
> 1. I see no ARP whatsoever to the requested IP when DNSMasq handles the
> request.
> 2. When I request the fixed IP for a client with a random MAC, I
> instantly receive an ACK, then I see some unanswered ARP requests
> (*after*) as to "who has [IP just assigned]? Tell 192.168.1.1" where
> 192.168.1.1 is the DHCP server IP.
> 
> I end up in a situation where the dhcp.leases contains the fake MAC
> associated to the lease, while the ARP table contains the MAC of the
> fixed IP laptop (probably because I'm not sending any IP packet where
> the IP is associated to the fake MAC, so the switch cannot learn it).
> 
> I have observed that Windows 10 has a mechanism to prevent conflicts
> where, whenever a fixed IP is used/configured, after the link is up an
> ARP probe is sent with its own IP. In case it gets answered, the client
> keeps silent and start using a link local IPv4 (169). Yet I have
> tested with a very old laptop running Windows 3.1 and I can replicate
> the issue.
> But basically, it is puzzling that the device is ARPing *after* the DHCP
> distributed the IP.
> 
> *The all issue seems to boil down to:* why does DNSMasq not check if the
> IP is free before assigning it?
> I thought that unless option "-5" or "--no-ping" was set, DNSMasq would
> always ping once to the assigned IP *before* assignment (I controlled in
> the code and see that actually, there is a mechanism to store the
> positive identification as well as to blacklist IP's in case a client is
> constantly coming back).
> The only ARP I see in this case is *after* the IP is assigned. How come
> DNSMasq is not trying to ping before assignment? Is there an option to
> force this behavior (from the code I guess not)? Is DNSMasq also somehow
> relying on the ARP table and flags that are set on reachability? or
> solely on the _non_ answer to ping?
> 
> Thanks a lot for your assistance.
> 
> Regards,
> Bernard
> 
> Scapy forged packet (I know the source MAC does not match the client
> MAC, but I deem this good enough for testing, AFAIK it is a legal packet):
>

[Dnsmasq-discuss] Duplicate IP detection with fixed IP

2018-09-18 Thread Bernard CLABOTS
 Hi all,   I have been trying to replicate an issue of IP conflict on Open-WRT, 
the issue is randomly seen, and I expect in real life, it is related to a 
de-sync of the lease data base with the actual situation (in case a switch is 
between the client and the server and the server is rebooted e.g., so that the 
client acts as though it would have a fixed IP. Reported as seen as well when 
moving a client from one setup to another setup where the IP that it used to 
receive is used on the LAN).
   I tested with 2 different versions of dnsmasq (2.78 and 2.79).
   I use Scapy to forge DHCP Requests (see further).
Setup:I have a laptop with a fixed IP inside the range of the DHCP 
(192.168.1.0/26). I then forge a Request of that IP using scapy and I cannot 
explain the behavior:1. I see no ARP whatsoever to the requested IP when 
DNSMasq handles the request.2. When I request the fixed IP for a client with a 
random MAC, I instantly receive an ACK, then I see some unanswered ARP requests 
(*after*) as to "who has [IP just assigned]? Tell 192.168.1.1" where 
192.168.1.1 is the DHCP server IP.
I end up in a situation where the dhcp.leases contains the fake MAC associated 
to the lease, while the ARP table contains the MAC of the fixed IP laptop 
(probably because I'm not sending any IP packet where the IP is associated to 
the fake MAC, so the switch cannot learn it).
I have observed that Windows 10 has a mechanism to prevent conflicts where, 
whenever a fixed IP is used/configured, after the link is up an ARP probe is 
sent with its own IP. In case it gets answered, the client keeps silent and 
start using a link local IPv4 (169). Yet I have tested with a very old 
laptop running Windows 3.1 and I can replicate the issue.But basically, it is 
puzzling that the device is ARPing *after* the DHCP distributed the IP.

*The all issue seems to boil down to:* why does DNSMasq not check if the IP is 
free before assigning it?
I thought that unless option "-5" or "--no-ping" was set, DNSMasq would always 
ping once to the assigned IP *before* assignment (I controlled in the code and 
see that actually, there is a mechanism to store the positive identification as 
well as to blacklist IP's in case a client is constantly coming back).The only 
ARP I see in this case is *after* the IP is assigned. How come DNSMasq is not 
trying to ping before assignment? Is there an option to force this behavior 
(from the code I guess not)? Is DNSMasq also somehow relying on the ARP table 
and flags that are set on reachability? or solely on the _non_ answer to ping?
Thanks a lot for your assistance.
Regards,Bernard
Scapy forged packet (I know the source MAC does not match the client MAC, but I 
deem this good enough for testing, AFAIK it is a legal packet):dhcp_request = 
Ether(dst='ff:ff:ff:ff:ff:ff')/IP(src='0.0.0.0', 
dst='255.255.255.255')/UDP(dport=67, 
sport=68)/BOOTP(xid=RandInt())/DHCP(options=[('message-type', 
'request'),("server_id","192.168.1.1"),("requested_addr","192.168.1.34"),("hostname","Scapy"),
 'end'])
dhcp_ack = srp1(dhcp_request, iface='enp9s0')___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss