Bug #38699 for dhcp-public: dhcp-4.2.5-27.0.1.el7_0.2 - dhcrelay drops responses inappropriately

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 <glasgow@beer.net>

---

On Thu Aug 27 18:53:53 2015, glasgow@beer.net wrote: > 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. > Hi Michael, Many thinks for taking the time and trouble to write up your use case. On the basis of your response, we are now considering potential changes to the relay code in relation to interfaces - but this ticket will still have to compete for engineering resources against other worthy bug reports and feature requests. So whether or not anything is done is not definite. But I thought you might like to know that your input has in fact caused us to reconsider our stance, even though we might not be able to address the issue in the immediate future. Kind regards, Cathy

---