@dfranusic completed a prototype authenticator setup using hostapd which provides a per interface 802.1x authenticator: 802.1x-overview.pdf
Some relevant questions from Moti:
It is important to include information on the Linux kernel support so we’ll disclose gaps and work with the Linux community on mitigation
It can be helpful to indicate what specific operations are expected by the switch hardware
It should be possible to globally enable/disable 802.1x on the switch device and on every port in specific, the 'detection' operation is done only if 802.1x is enabled
I expect 802.1x to be supported on physical interfaces only (e.g. swp1) and such that are not part of bond interfaces, is it fully supported by hostapd?
We should add information on the use of guest vlan in case authentication fails (another option is to simply reject any traffic)
Do we see a need for the RADIUS to send back configuration such as VLAN assignment?
It can be useful to force a single Supplicant or allow multiple ones at the port
It can be useful to bypass 802.1x authentication for specific MAC addresses and/or VLANs
Are there specific counters/log/traps?
Some relevant answers from @dfranusic:
Understood. It would be best to have this discussion with the netdev community. As far as we are aware there is no specific support within the Linux kernel for 802.1x use-cases at the moment.
Most of the operations are managed in userspace (hostapd), the switch should be able to send L2 packets to the userspace until a device is “approved”. And once userspace approves the access the flow should be offloaded back to the switch.
It is not clear what is ‘detection’, could you please clarify? We do agree with the first part of the point and this is generally the question of integration.
The current implementation of hostapd does not impose this limitation. The hostapd only requires full L2 frames. For example tap interfaces would not be supported, but any other net L2 capable interface is sufficient for the current design with hostapd.
Additional VLANs can be set by hostapd (or other tool) upon authentication and authorization or failure to do so. This is part of the integration process and will require additional configuration and likely patching of hostapd linked with RADIUS backend to support VLAN tagging. This feature is mostly dependent on RADIUS.
Same as the above.
We only see use-case to support only one supplicant (client device) per port interface. Could you share the use-case for multiple supplicants per port interface?
This could be part of the integration effort. Within the document that has been provided this would fall into firewall configuration. We should focus on the 802.1x protocol implementation and how to efficiently combine user-space & ASIC integration.
There are metrics that can be collected from hostapd and from firewall (e.g. nftables). Which information would be possible to collect from switch ASIC directly?
Additional responses from Moti:
(1) In the 802.1x-overview.pdf document I see the use of 'shell script' so need to discuss if this is an acceptable path
(3) see page#2 in 802.1x-overview.pdf document (under 'initialization')
(7) for example the use-case of an access-point that is connected to the port
(8) agree
(9) maybe indication on mac movement (this can be considered as another feature on top of 802.1x though)
@dfranusic completed a prototype authenticator setup using hostapd which provides a per interface 802.1x authenticator: 802.1x-overview.pdf
Some relevant questions from Moti:
Some relevant answers from @dfranusic:
Additional responses from Moti: (1) In the 802.1x-overview.pdf document I see the use of 'shell script' so need to discuss if this is an acceptable path (3) see page#2 in 802.1x-overview.pdf document (under 'initialization') (7) for example the use-case of an access-point that is connected to the port (8) agree (9) maybe indication on mac movement (this can be considered as another feature on top of 802.1x though)