ISC DHCP Users

dhcrelay and interfaces

Classic

List

Threaded

4 messages Options

Shawn Routhier

dhcrelay and interfaces

We have received some tickets about the handling of

interfaces in dhcrelay (41547 & 42849). These deal with

the need to have the relay listen for responses from

the server via the -i <interface> option and the possibility

of packets being duplicated. (This can also be found at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648401)

There is a patch (with some variations) that uses -i for

interfaces that would lead to the client (downstream)

and that auto-discovers the rest of the interfaces and

uses them to receive responses from any servers.

This patch has been in debian for some time and we

are investigating adding it to the main code. However

there is one issue we are considering. If the admin

sets up their interfaces with -i they can limit the interfaces

the relay will accept “responses” from. With the debian

patch it appears that the relay will accept responses from

all interfaces.

In theory I can see this as a possible problem for somebody.

In practice I’m not sure that it is an issue. While we are

considering addressing the underlying issues in other ways

I wanted to check with the community and see if anybody

actually has had a problem in practice (or equally decided

not to use the patch due to this issue).

regards,

Shawn Routhier

ISC DHCP

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Simon Hobson-2

Re: dhcrelay and interfaces

Shawn Routhier <[hidden email]> wrote:

> There is a patch (with some variations) that uses -i for
> interfaces that would lead to the client (downstream)
> and that auto-discovers the rest of the interfaces and
> uses them to receive responses from any servers.
>
> ...If the admin
> sets up their interfaces with -i they can limit the interfaces
> the relay will accept “responses” from. With the debian
> patch it appears that the relay will accept responses from
> all interfaces.

I haven't used dhcrelay with or without the patches ...
But, while it would be more work, would it be an option to add an extra option for interfaces to listen to server replies on - so something like '-i if [if ...]' for interfaces to listen to broadcasts on, and '-I if [if ...]' for interfaces to listen to non-broadcast packets on ?

Doing it that way means that existing users (without patch) will see no difference in behaviour (ie the change would be backwards compatible with existing configs).

As another thought, I'm guessing that the auto-configured interfaces are only opening a socket and receiving unicast packets. If so, then the security issue can be worked around with firewall rules.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Simon Hobson

Re: dhcrelay and interfaces

In reply to this post by Shawn Routhier

Shawn Routhier <[hidden email]> wrote:

Shawn Routhier

Re: dhcrelay and interfaces

In reply to this post by Simon Hobson-2

> On Aug 1, 2016, at 1:26 PM, Simon Hobson <[hidden email]> wrote:
>
> Shawn Routhier <[hidden email]> wrote:
>
>> There is a patch (with some variations) that uses -i for
>> interfaces that would lead to the client (downstream)
>> and that auto-discovers the rest of the interfaces and
>> uses them to receive responses from any servers.
>>
>> ...If the admin
>> sets up their interfaces with -i they can limit the interfaces
>> the relay will accept “responses” from. With the debian
>> patch it appears that the relay will accept responses from
>> all interfaces.
>
> I haven't used dhcrelay with or without the patches ...
> But, while it would be more work, would it be an option to add an extra option for interfaces to listen to server replies on - so something like '-i if [if ...]' for interfaces to listen to broadcasts on, and '-I if [if ...]' for interfaces to listen to non-broadcast packets on ?

It wouldn’t be a question of broadcast vs non-broadcast as that would require more work given
how the code handles the sockets.

One option we are considering is to go with something like the v6 code and have an option for
upper interfaces (connect to the server) and lower interfaces (connected to the clients).

>
> Doing it that way means that existing users (without patch) will see no difference in behaviour (ie the change would be backwards compatible with existing configs).

I think that might be true for people using vanilla ISC DHCP. For people using one of the
patches they would see a change as they would need to add the upstream interfaces instead
of letting auto-configure do it for them. While I don’t feel as constrained to ensure backwards
compatibility with other peoples changes or additions I also don’t wish to break them
if I don’t have to.

>
> As another thought, I'm guessing that the auto-configured interfaces are only opening a socket and receiving unicast packets. If so, then the security issue can be worked around with firewall rules.

I don’t think so.

regards,
Shawn Routhier
ISC
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users