From glasgow@beer.net Thu Aug 27 18:53:53 2015 In-Reply-To: from Cathy Almond via RT at "Aug 27, 2015 04:39:18 pm" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Mailer: ELM [version 2.4ME+ PL54 (25)] X-RT-Interface: API content-type: text/plain; charset="utf-8" Message-ID: <201508271853.t7RIrmCA021180@dark.beer.net> X-RT-Original-Encoding: utf-8 Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by bugs.isc.org (Postfix) with ESMTP id D1ED371B583 for ; Thu, 27 Aug 2015 18:53:52 +0000 (UTC) Received: from dark.beer.net (dark.beer.net [204.145.225.20]) by mx.pao1.isc.org (Postfix) with ESMTP id DBCA23493CF for ; Thu, 27 Aug 2015 18:53:50 +0000 (UTC) Received: from dark.beer.net (glasgow@localhost [127.0.0.1]) by dark.beer.net (8.13.8/8.13.8) with ESMTP id t7RIrn2Y021181 for ; Thu, 27 Aug 2015 13:53:49 -0500 (CDT) Received: (from glasgow@localhost) by dark.beer.net (8.13.8/8.13.8/Submit) id t7RIrmCA021180 for dhcp-review@isc.org; Thu, 27 Aug 2015 13:53:48 -0500 (CDT) Delivered-To: dhcp-review@bugs.isc.org Subject: Re: [ISC-Bugs #38699] dhcp-4.2.5-27.0.1.el7_0.2 - dhcrelay drops responses inappropriately Return-Path: X-Original-To: dhcp-review@bugs.isc.org Date: Thu, 27 Aug 2015 13:53:48 -0500 (CDT) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org To: dhcp-review@isc.org From: "Michael Glasgow" RT-Message-ID: Content-Length: 2870 Cathy Almond via RT wrote: > Thanks for this report, > > This behaviour is something that has been around in ISC DHCP for > a very long time - and we agree that it can result in duplicate > requests being received by the DHCP servers, but at the same time, > it should not be causing any problems. > > As this has been the way that ISC DHCP has operated for a long > time, we're a little reluctant to try to change it now - but before > we make that decision, we'd first like to check back with you > whether or not this is causing you a significant operational issue, > beyond the inevitable logging of the duplicated requests on the > same subnet as the DHCP server? Appreciate your response. I abandoned the ISC relay code for this reason, so I guess you could say it was significant for me. In my case, the subnets south of the relay ("s2" in my example) are all dmz subnets, so traffic to/from the relay host's trusted interface is scrutinized very carefully. Security-wise, it was not acceptable for the relay to respond to requests on the trsuted side of the network, in case an attacker somehow got control of the relay host. Of course, I understand that if they got root on the relay host, they could do so regardless, but with this broken behavior it becomes much more difficult for my monitoring to detect them doing so. In other words, by watching the network I can't easily distinguish the "normal" broken behavior from an attack signature. What makes this worse is that Linux processes traffic to/from AF_PACKET sockets such that iptables cannot filter these out. So that was my use case -- a very strict security posture which rendered ISC's code too painful (though not impossible) to use. I could've worked around it somehow, but I found other code to use instead. Additionally, purely from a functional standpoint I must say I view the blanket assertion that it should not be causing any problems with some skepticism. At a minimum, it could easily cause unexpected behavior where the user has defined classes based on which relay a request came through. You could also imagine a case where the relay is pointing at a different dhcpd than the dhcpd running on s1, with a very different configuration, so that the client hosts are configured differently based on who wins the race. I wouldn't assume that folks are ok with this behavior just because you don't get a ton of bug reports about it. I've been doing IT for a very long time, and it was not easy to figure out what was going on here. If I hadn't figured out why it was happening, I would've just silently moved on to another vendor's code and never submitted the report. Could be plenty of people doing the same thing... not sure you would really know unless you have separate metrics for users of dhcrelay as opposed to dhcpd itself. -- Michael Glasgow