Bug#1061769: Unexpected VLAN behavior with KEA DHCP

2024-03-14 Thread kristofer.hansson 
Hi Paride.

Thanks for the answer and while it was not the answer I hoped for I completely 
understand and sympathize with your decision.

I'll see if I can get the ISC team to take another look at the issue.

Regards Kristofer

EQUANS Mail Disclaimer: https://www.equans.com/disclaimer/disclaimer-mail/en

Bug#1061769: Unexpected VLAN behavior with KEA DHCP

2024-02-26 Thread Paride Legovini 
Control: tags -1 + wontfix

On 2024-01-29 15:27, kristofer.hans...@icomera.com wrote:
> Package: kea-dhcp4-server
> Version: 2.2.0-6
> 
> Hi, this version (and from what I believe all versions) of kea-dhcp4-server
> (and probably kea-dhcp6-server) handles vlan tagged traffic in a quite
> unintuitive way. When the server is set up in raw socket mode it will accept 
> all
> broadcasted DHCP requests regardless of VLAN tagging. It will then send a
> response untagged, again regardless of initial VLAN tag. See below for a 
> packet
> trace where this happens.
> 
> This has been reported to the ISC team quite some time ago here:
> https://gitlab.isc.org/isc-projects/kea/-/issues/1117.
> A patch has been provided to the ISC team which they have not applied (I can't
> say why): https://github.com/isc-projects/kea/pull/119.
> The file that is patched has been more or less unchanged since the patch was
> created and should still apply (it did for me on 2.2.0-6).
> 
> This behavior was not present in isc-dhcp-server as they filtered out VLAN
> tagged broadcasts from what I can tell, so the behavior is changed between the
> two DHCP server services.
> 
> As I see it there are two things that shouldn't happen here:
> 1. A DHCP server not explicitly configured to listen to VLAN traffic should 
> not
>    respond to that traffic.
> 2. If a DHCP server answers DHCP broadcasts on a VLAN tagged network it should
>    respond on the same VLAN network.
> 
> My suggestion would be to include the patch 
> (https://github.com/isc-projects/kea/pull/119)
> to filter out any tagged traffic, as this is inline with how dhcpd from
> isc-dhcp-server worked.

Hello Kristofer and thanks for this bug report.

After looking at the state of the upstream bug and and the patches you
pointed to, and discussing the issue with the other Debian Kea maintainers,
our opinion is that we should not patch the Debian package to include the
requested functionality. There are many reasons for this, in I think the
two most important ones are:

* The issue is not trivial, and there's the risk to introduce incomplete
or buggy code we can't commit to fix or maintain.

* If what ISC will ship at some point will be different from what Debian
shipped, maybe in a stable release, we'll end up in a difficult to handle
situation, with no clear or easy upgrade path for uses that ended up
relying on the Debian specific implementation.

I think the way forward here is asking upstream what the plans are, and
whether there are ways users interested in the feature can help landing
it.

Cheers,

Paride

Bug#1061769: Unexpected VLAN behavior with KEA DHCP

2024-01-29 Thread kristofer.hansson 
Package: kea-dhcp4-server
Version: 2.2.0-6

Hi, this version (and from what I believe all versions) of kea-dhcp4-server
(and probably kea-dhcp6-server) handles vlan tagged traffic in a quite
unintuitive way. When the server is set up in raw socket mode it will accept all
broadcasted DHCP requests regardless of VLAN tagging. It will then send a
response untagged, again regardless of initial VLAN tag. See below for a packet
trace where this happens.

This has been reported to the ISC team quite some time ago here:
https://gitlab.isc.org/isc-projects/kea/-/issues/1117.
A patch has been provided to the ISC team which they have not applied (I can't
say why): https://github.com/isc-projects/kea/pull/119.
The file that is patched has been more or less unchanged since the patch was
created and should still apply (it did for me on 2.2.0-6).

This behavior was not present in isc-dhcp-server as they filtered out VLAN
tagged broadcasts from what I can tell, so the behavior is changed between the
two DHCP server services.

As I see it there are two things that shouldn't happen here:
1. A DHCP server not explicitly configured to listen to VLAN traffic should not
   respond to that traffic.
2. If a DHCP server answers DHCP broadcasts on a VLAN tagged network it should
   respond on the same VLAN network.

My suggestion would be to include the patch 
(https://github.com/isc-projects/kea/pull/119)
to filter out any tagged traffic, as this is inline with how dhcpd from
isc-dhcp-server worked.

Packet trace of a DHCP broadcast offer/request comming in on VLAN 20 and being
returned untagged.
$ tcpdump -evnni eth0 port bootps or port bootpc
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 
bytes
11:09:56.861903 98:90:96:c1:ff:a0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 346: vlan 20, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, 
id 60207, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
98:90:96:c1:ff:a0, length 300, xid 0xf7a80c8d, Flags [none]
  Client-Ethernet-Address 98:90:96:c1:ff:a0
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Parameter-Request (55), length 14:
  Subnet-Mask (1), Classless-Static-Route (121), Default-Gateway 
(3), Domain-Name-Server (6)
  Hostname (12), Domain-Name (15), MTU (26), BR (28)
  Static-Route (33), Lease-Time (51), Server-ID (54), RN (58)
  RB (59), Unknown (119)
MSZ (57), length 2: 1472
Client-ID (61), length 19: hardware-type 255, 
96:c1:ff:a0:00:01:00:01:2d:14:50:63:98:90:96:c1:ff:a0
SLP-NA (80), length 0""
Unknown (145), length 1: 1
11:09:56.862416 e2:82:0f:6b:8e:b9 > 98:90:96:c1:ff:a0, ethertype IPv4 (0x0800), 
length 341: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), 
length 327)
10.101.64.1.67 > 10.101.64.100.68: BOOTP/DHCP, Reply, length 299, xid 
0xf7a80c8d, Flags [none]
  Your-IP 10.101.64.100
  Client-Ethernet-Address 98:90:96:c1:ff:a0
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Offer
Subnet-Mask (1), length 4: 255.255.255.0
Default-Gateway (3), length 4: 10.101.64.1
Domain-Name-Server (6), length 4: 10.101.64.1
MTU (26), length 2: 1350
Lease-Time (51), length 4: 600
Server-ID (54), length 4: 10.101.64.1
Client-ID (61), length 19: hardware-type 255, 
96:c1:ff:a0:00:01:00:01:2d:14:50:63:98:90:96:c1:ff:a0
11:09:56.862829 98:90:96:c1:ff:a0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 346: vlan 20, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, 
id 45786, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
98:90:96:c1:ff:a0, length 300, xid 0xf7a80c8d, Flags [none]
  Client-Ethernet-Address 98:90:96:c1:ff:a0
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
Requested-IP (50), length 4: 10.101.64.100
DHCP-Message (53), length 1: Request
Server-ID (54), length 4: 10.101.64.1
Parameter-Request (55), length 14:
  Subnet-Mask (1), Classless-Static-Route (121), Default-Gateway 
(3), Domain-Name-Server (6)
  Hostname (12), Domain-Name (15), MTU (26), BR (28)
  Static-Route (33), Lease-Time (51), Server-ID (54), RN (58)
  RB (59), Unknown (119)
MSZ (57), length 2: 1472
Client-ID (61), length 19: hardware-type 255, 
96:c1:ff:a0:00:01:00:01:2d:14:50:63:98:90:96:c1:ff:a0
Unknown (145), length 1: 1
11:09:56.864127 e2:82:0f:6b:8e:b9 > 98:90:96:c1:ff:a0, ethertype IPv4 (0x0800), 
length 341: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), 
length 327)