<div dir="ltr">><span style="font-size:12.8000001907349px">That's my opinion too (although I can see a flip side to the coin: if</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>clients honor NAKs from any sever, then a rogue machine could break a</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>local noetwork by NAKing any and all DHCPREQUESTs, effectively DoSing</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>the whole segment at least).</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Oh definitely. DHCPNAKs are definitely not a good way to protect against rogue DHCP servers. Packet filtering (e.g. DHCP snooping or UDP drop rules) are much better at that. I was just pointing out that if we are teaching clients to ignore NAKs from other servers, we might as well have the servers stop sending NAKs in response to traffic to other servers. "dhcp authoritative" in the dnsmasq case would then just mean it accepts any renewal.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">RFC 2131 says a server SHOULD send a DHCPNAK if it detects a DHCP</span></div><span style="font-size:12.8000001907349px">>request for e.g. the wrong network. It also says "If the client</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>receives a DHCPNAK message, the client restarts the configuration</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>process", which, while there is no "MUST" in it, seems to me like a</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>non-optional requirement to honor DHCPNAKs.</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Right, so then wouldn't the referenced busy-box patch be making the client non-compliant?</span></div><div><span style="font-size:12.8000001907349px"><a href="http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0">http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0</a></span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 2:51 AM, Albert ARIBAUD <span dir="ltr"><<a href="mailto:albert.aribaud@free.fr" target="_blank">albert.aribaud@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kevin,<br>
<br>
Le Mon, 1 Jun 2015 02:02:27 -0700, Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> a<br>
écrit :<br>
<span class=""><br>
> I understand, but that eliminates the whole 'correcting rouge dhcp offers'<br>
> part of the authoritative mode.<br>
><br>
> If we are teaching clients to ignore NAKs from other DHCP servers, why do<br>
> DHCP servers like dnsmasq generate them in the first place? Wouldn't it be<br>
> logically consistent to make a change to dnsmasq to prevent it from<br>
> generating a NAK if the client is communicating with a different server?<br>
<br>
</span>That's my opinion too (although I can see a flip side to the coin: if<br>
clients honor NAKs from any sever, then a rogue machine could break a<br>
local noetwork by NAKing any and all DHCPREQUESTs, effectively DoSing<br>
the whole segment at least).<br>
<span class=""><br>
> Is the client behavior regarding NAKs outlined in one of the DHCP RFCs? It<br>
> does seem like there is a lot of confusion around what authoritative<br>
> servers should be doing.<br>
<br>
</span>RFC 2131 says a server SHOULD send a DHCPNAK if it detects a DHCP<br>
request for e.g. the wrong network. It also says "If the client<br>
receives a DHCPNAK message, the client restarts the configuration<br>
process", which, while there is no "MUST" in it, seems to me like a<br>
non-optional requirement to honor DHCPNAKs.<br>
<span class=""><br>
> On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko <<a href="mailto:themiron@mail.ru">themiron@mail.ru</a>><br>
> wrote:<br>
><br>
> > Hi Kevin,<br>
> ><br>
> > Ignoring all naks – would be, but the fix is different.<br>
> ><br>
> > That fix ignores all naks except from the selected/requested server only,<br>
> > it’s ok.<br>
> ><br>
> ><br>
> ><br>
> > Best Regards, Vladislav Grishenko<br>
> ><br>
> ><br>
> ><br>
</span>> > *From:* Kevin Benton [mailto:<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>]<br>
> > *Sent:* Wednesday, May 27, 2015 9:32 AM<br>
> > *To:* Vladislav Grishenko<br>
> > *Cc:* Brian Haley; Simon Kelley; <a href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk">dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> > *Subject:* Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue<br>
<div><div class="h5">> ><br>
> ><br>
> ><br>
> > That fix is interesting. Doesn't ignoring a NAK sort of defeat the point<br>
> > of the 'authoritative' NAKing in the first place?<br>
> ><br>
> ><br>
> ><br>
> > On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko <<a href="mailto:themiron@mail.ru">themiron@mail.ru</a>><br>
> > wrote:<br>
> ><br>
> > > On 02/02/2015 05:47 PM, Brian Haley wrote:<br>
> > > >><br>
> > > >>> The one thing I'm curious about is if dnsmasq is restarted while a<br>
> > > >>> VM holds a lease, how will it respond?  As someone else has<br>
> > > >>> pointed-out to me - isc-dhcp will respond with a DHCPNAK in that<br>
> > > >>> case, and wondered why there would be a difference with dnsmasq.<br>
> > > >>> Different interpretation of an RFC?<br>
> > > >><br>
> > > >><br>
> > > >> If by "dnsmasq is restarted" you mean "dnsmasq is restarted and<br>
> > > >> therefore has its lease database deleted", then the RFC says that if<br>
> > > >> a server gets a renewal for an unknown lease, it should return<br>
> > > >> DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is<br>
> > > >> set, when instead it quietly re-creates the lease.<br>
> > > ><br>
> > > > Yes, your assumption is correct, as --leasefile-ro is used it knows of<br>
> > > > no current leases, and by default get a DHCPNAK.<br>
> > > ><br>
> > > >> dhcp-authoritative gives permission to dnsmasq to violate the RFC in<br>
> > > >> a way which is useful in certain circumstances.<br>
> > > ><br>
> > > > Thanks, it does seem to do what I want with my initial testing.<br>
> > ><br>
> > > Hi Simon,<br>
> > ><br>
> > > Replying to my old thread since using --dhcp-authoritative seems to have<br>
> > > introduced an issue where a DHCP client can get a NAK when using multiple<br>
> > > dnsmasq servers on the same subnet (they both have the same host<br>
> > > information, >1 running just to get HA).<br>
> > ><br>
> > > Short story is that both dnsmasq's return the same lease info, but when<br>
> > the<br>
> > > client ACKs (sending to broadcast), one agent ACKs and the other agent<br>
> > > NAKs.<br>
> > > The tcpdump shows this better than I'm describing:<br>
> > ><br>
> > > <a href="https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html" target="_blank">https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html</a><br>
> > ><br>
> > > Does that seem like normal operation to you?  Does this second dnsmasq<br>
> > > assume this response is from a rogue server and NAKs since it didn't send<br>
> > out<br>
> > > the offer?<br>
> > ><br>
> ><br>
> > Hi Brian,<br>
> ><br>
> > Second dnsmasq assume the client request is to another server and responds<br>
> > with NAK in authoritative mode.<br>
> > The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't<br>
> > check server id for anything but offer packet.<br>
> > Bug is already fixed in bb 1.23.x, see commit<br>
> ><br>
> > <a href="http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52" target="_blank">http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52</a><br>
> > e588c0<br>
> ><br>
> > Best Regards, Vladislav Grishenko<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Dnsmasq-discuss mailing list<br>
> > <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> > <a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> ><br>
> > Kevin Benton<br>
> ><br>
><br>
><br>
><br>
<br>
<br>
</div></div>Amicalement,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Albert.<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>