| Message ID | 20220310142320.611738-1-schultz.hans+netdev@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Extend locked port feature with FDB locked flag (MAC-Auth/MAB) | expand |
On Thu, Mar 10, 2022 at 03:23:17PM +0100, Hans Schultz wrote: > This patch set extends the locked port feature for devices > that are behind a locked port, but do not have the ability to > authorize themselves as a supplicant using IEEE 802.1X. > Such devices can be printers, meters or anything related to > fixed installations. Instead of 802.1X authorization, devices > can get access based on their MAC addresses being whitelisted. > > For an authorization daemon to detect that a device is trying > to get access through a locked port, the bridge will add the > MAC address of the device to the FDB with a locked flag to it. > Thus the authorization daemon can catch the FDB add event and > check if the MAC address is in the whitelist and if so replace > the FDB entry without the locked flag enabled, and thus open > the port for the device. > > This feature is known as MAC-Auth or MAC Authentication Bypass > (MAB) in Cisco terminology, where the full MAB concept involves > additional Cisco infrastructure for authorization. There is no > real authentication process, as the MAC address of the device > is the only input the authorization daemon, in the general > case, has to base the decision if to unlock the port or not. > > With this patch set, an implementation of the offloaded case is > supplied for the mv88e6xxx driver. When a packet ingresses on > a locked port, an ATU miss violation event will occur. When When do you get an ATU miss violation? In case there is no FDB entry for the SA or also when there is an FDB entry, but it points to a different port? I see that the bridge will only create a "locked" FDB entry in case there is no existing entry, but it will not transition an existing entry to "locked" state. I guess ATU miss refers to an actual miss and not mismatch. The HW I work with doesn't have the ability to generate such notifications, but it can trap packets on MISS (no entry) or MISMATCH (exists, but with different port). I believe that in order to support this feature we need to inject MISS-ed packets to the Rx path so that eventually the bridge itself will create the "locked" entry as opposed to notifying the bridge about the entry as in your case. > handling such ATU miss violation interrupts, the MAC address of > the device is added to the FDB with a zero destination port > vector (DPV) and the MAC address is communicated through the > switchdev layer to the bridge, so that a FDB entry with the > locked flag enabled can be added. > > Hans Schultz (3): > net: bridge: add fdb flag to extent locked port feature > net: switchdev: add support for offloading of fdb locked flag > net: dsa: mv88e6xxx: mac-auth/MAB implementation Please extend tools/testing/selftests/net/forwarding/bridge_locked_port.sh with new test cases for this code. > > drivers/net/dsa/mv88e6xxx/Makefile | 1 + > drivers/net/dsa/mv88e6xxx/chip.c | 10 +-- > drivers/net/dsa/mv88e6xxx/chip.h | 5 ++ > drivers/net/dsa/mv88e6xxx/global1.h | 1 + > drivers/net/dsa/mv88e6xxx/global1_atu.c | 29 +++++++- > .../net/dsa/mv88e6xxx/mv88e6xxx_switchdev.c | 67 +++++++++++++++++++ > .../net/dsa/mv88e6xxx/mv88e6xxx_switchdev.h | 20 ++++++ > drivers/net/dsa/mv88e6xxx/port.c | 11 +++ > drivers/net/dsa/mv88e6xxx/port.h | 1 + > include/net/switchdev.h | 3 +- > include/uapi/linux/neighbour.h | 1 + > net/bridge/br.c | 3 +- > net/bridge/br_fdb.c | 13 +++- > net/bridge/br_input.c | 11 ++- > net/bridge/br_private.h | 5 +- > 15 files changed, 167 insertions(+), 14 deletions(-) > create mode 100644 drivers/net/dsa/mv88e6xxx/mv88e6xxx_switchdev.c > create mode 100644 drivers/net/dsa/mv88e6xxx/mv88e6xxx_switchdev.h > > -- > 2.30.2 >
On mån, mar 14, 2022 at 17:50, Ido Schimmel <idosch@idosch.org> wrote: > On Thu, Mar 10, 2022 at 03:23:17PM +0100, Hans Schultz wrote: >> This patch set extends the locked port feature for devices >> that are behind a locked port, but do not have the ability to >> authorize themselves as a supplicant using IEEE 802.1X. >> Such devices can be printers, meters or anything related to >> fixed installations. Instead of 802.1X authorization, devices >> can get access based on their MAC addresses being whitelisted. >> >> For an authorization daemon to detect that a device is trying >> to get access through a locked port, the bridge will add the >> MAC address of the device to the FDB with a locked flag to it. >> Thus the authorization daemon can catch the FDB add event and >> check if the MAC address is in the whitelist and if so replace >> the FDB entry without the locked flag enabled, and thus open >> the port for the device. >> >> This feature is known as MAC-Auth or MAC Authentication Bypass >> (MAB) in Cisco terminology, where the full MAB concept involves >> additional Cisco infrastructure for authorization. There is no >> real authentication process, as the MAC address of the device >> is the only input the authorization daemon, in the general >> case, has to base the decision if to unlock the port or not. >> >> With this patch set, an implementation of the offloaded case is >> supplied for the mv88e6xxx driver. When a packet ingresses on >> a locked port, an ATU miss violation event will occur. When > > When do you get an ATU miss violation? In case there is no FDB entry for > the SA or also when there is an FDB entry, but it points to a different > port? I see that the bridge will only create a "locked" FDB entry in > case there is no existing entry, but it will not transition an existing > entry to "locked" state. I guess ATU miss refers to an actual miss and > not mismatch. > On a locked port, I get ATU miss violations when there is no FDB entry for the SA, while if there is an entry but it is not assigned to the port, then I get an ATU member violation (which I have now masked on locked ports to limit unwanted interrupts). So it seems to me that my 'ATU miss' corresponds to your MISS and my 'ATU member' corresponds to your MISMATCH. Since I inject an entry with destination port vector (DPV) zero I get member violations after the first miss violation. > The HW I work with doesn't have the ability to generate such > notifications, but it can trap packets on MISS (no entry) or MISMATCH > (exists, but with different port). I believe that in order to support > this feature we need to inject MISS-ed packets to the Rx path so that > eventually the bridge itself will create the "locked" entry as opposed > to notifying the bridge about the entry as in your case. > This seems to me to be the way forward in your case. What kind or family of chips is your HW based on? >> handling such ATU miss violation interrupts, the MAC address of >> the device is added to the FDB with a zero destination port >> vector (DPV) and the MAC address is communicated through the >> switchdev layer to the bridge, so that a FDB entry with the >> locked flag enabled can be added. >> >> Hans Schultz (3): >> net: bridge: add fdb flag to extent locked port feature >> net: switchdev: add support for offloading of fdb locked flag >> net: dsa: mv88e6xxx: mac-auth/MAB implementation > > Please extend tools/testing/selftests/net/forwarding/bridge_locked_port.sh > with new test cases for this code. > Shall do. >> >> drivers/net/dsa/mv88e6xxx/Makefile | 1 + >> drivers/net/dsa/mv88e6xxx/chip.c | 10 +-- >> drivers/net/dsa/mv88e6xxx/chip.h | 5 ++ >> drivers/net/dsa/mv88e6xxx/global1.h | 1 + >> drivers/net/dsa/mv88e6xxx/global1_atu.c | 29 +++++++- >> .../net/dsa/mv88e6xxx/mv88e6xxx_switchdev.c | 67 +++++++++++++++++++ >> .../net/dsa/mv88e6xxx/mv88e6xxx_switchdev.h | 20 ++++++ >> drivers/net/dsa/mv88e6xxx/port.c | 11 +++ >> drivers/net/dsa/mv88e6xxx/port.h | 1 + >> include/net/switchdev.h | 3 +- >> include/uapi/linux/neighbour.h | 1 + >> net/bridge/br.c | 3 +- >> net/bridge/br_fdb.c | 13 +++- >> net/bridge/br_input.c | 11 ++- >> net/bridge/br_private.h | 5 +- >> 15 files changed, 167 insertions(+), 14 deletions(-) >> create mode 100644 drivers/net/dsa/mv88e6xxx/mv88e6xxx_switchdev.c >> create mode 100644 drivers/net/dsa/mv88e6xxx/mv88e6xxx_switchdev.h >> >> -- >> 2.30.2 >>
On Tue, Mar 15, 2022 at 09:59:49AM +0100, Hans Schultz wrote: > On mån, mar 14, 2022 at 17:50, Ido Schimmel <idosch@idosch.org> wrote: > > On Thu, Mar 10, 2022 at 03:23:17PM +0100, Hans Schultz wrote: > >> This patch set extends the locked port feature for devices > >> that are behind a locked port, but do not have the ability to > >> authorize themselves as a supplicant using IEEE 802.1X. > >> Such devices can be printers, meters or anything related to > >> fixed installations. Instead of 802.1X authorization, devices > >> can get access based on their MAC addresses being whitelisted. > >> > >> For an authorization daemon to detect that a device is trying > >> to get access through a locked port, the bridge will add the > >> MAC address of the device to the FDB with a locked flag to it. > >> Thus the authorization daemon can catch the FDB add event and > >> check if the MAC address is in the whitelist and if so replace > >> the FDB entry without the locked flag enabled, and thus open > >> the port for the device. > >> > >> This feature is known as MAC-Auth or MAC Authentication Bypass > >> (MAB) in Cisco terminology, where the full MAB concept involves > >> additional Cisco infrastructure for authorization. There is no > >> real authentication process, as the MAC address of the device > >> is the only input the authorization daemon, in the general > >> case, has to base the decision if to unlock the port or not. > >> > >> With this patch set, an implementation of the offloaded case is > >> supplied for the mv88e6xxx driver. When a packet ingresses on > >> a locked port, an ATU miss violation event will occur. When > > > > When do you get an ATU miss violation? In case there is no FDB entry for > > the SA or also when there is an FDB entry, but it points to a different > > port? I see that the bridge will only create a "locked" FDB entry in > > case there is no existing entry, but it will not transition an existing > > entry to "locked" state. I guess ATU miss refers to an actual miss and > > not mismatch. > > > > On a locked port, I get ATU miss violations when there is no FDB entry > for the SA, while if there is an entry but it is not assigned to the > port, then I get an ATU member violation (which I have now masked on > locked ports to limit unwanted interrupts). > > So it seems to me that my 'ATU miss' corresponds to your MISS and my > 'ATU member' corresponds to your MISMATCH. Since I inject an entry with > destination port vector (DPV) zero I get member violations after the > first miss violation. Which causes packets to be silently dropped by the device? Sounds OK, I just want to verify I understand the behavior. > > > The HW I work with doesn't have the ability to generate such > > notifications, but it can trap packets on MISS (no entry) or MISMATCH > > (exists, but with different port). I believe that in order to support > > this feature we need to inject MISS-ed packets to the Rx path so that > > eventually the bridge itself will create the "locked" entry as opposed > > to notifying the bridge about the entry as in your case. > > > > This seems to me to be the way forward in your case. What kind or family > of chips is your HW based on? Nvidia Spectrum ASICs. Some users mentioned 802.1X support, but a requirement never materialized so we didn't work on it. > > >> handling such ATU miss violation interrupts, the MAC address of > >> the device is added to the FDB with a zero destination port > >> vector (DPV) and the MAC address is communicated through the > >> switchdev layer to the bridge, so that a FDB entry with the > >> locked flag enabled can be added. > >> > >> Hans Schultz (3): > >> net: bridge: add fdb flag to extent locked port feature > >> net: switchdev: add support for offloading of fdb locked flag > >> net: dsa: mv88e6xxx: mac-auth/MAB implementation > > > > Please extend tools/testing/selftests/net/forwarding/bridge_locked_port.sh > > with new test cases for this code. > > > > Shall do. Thanks! > > >> > >> drivers/net/dsa/mv88e6xxx/Makefile | 1 + > >> drivers/net/dsa/mv88e6xxx/chip.c | 10 +-- > >> drivers/net/dsa/mv88e6xxx/chip.h | 5 ++ > >> drivers/net/dsa/mv88e6xxx/global1.h | 1 + > >> drivers/net/dsa/mv88e6xxx/global1_atu.c | 29 +++++++- > >> .../net/dsa/mv88e6xxx/mv88e6xxx_switchdev.c | 67 +++++++++++++++++++ > >> .../net/dsa/mv88e6xxx/mv88e6xxx_switchdev.h | 20 ++++++ > >> drivers/net/dsa/mv88e6xxx/port.c | 11 +++ > >> drivers/net/dsa/mv88e6xxx/port.h | 1 + > >> include/net/switchdev.h | 3 +- > >> include/uapi/linux/neighbour.h | 1 + > >> net/bridge/br.c | 3 +- > >> net/bridge/br_fdb.c | 13 +++- > >> net/bridge/br_input.c | 11 ++- > >> net/bridge/br_private.h | 5 +- > >> 15 files changed, 167 insertions(+), 14 deletions(-) > >> create mode 100644 drivers/net/dsa/mv88e6xxx/mv88e6xxx_switchdev.c > >> create mode 100644 drivers/net/dsa/mv88e6xxx/mv88e6xxx_switchdev.h > >> > >> -- > >> 2.30.2 > >>
On 3/10/2022 6:23 AM, Hans Schultz wrote: > This patch set extends the locked port feature for devices > that are behind a locked port, but do not have the ability to > authorize themselves as a supplicant using IEEE 802.1X. > Such devices can be printers, meters or anything related to > fixed installations. Instead of 802.1X authorization, devices > can get access based on their MAC addresses being whitelisted. > > For an authorization daemon to detect that a device is trying > to get access through a locked port, the bridge will add the > MAC address of the device to the FDB with a locked flag to it. > Thus the authorization daemon can catch the FDB add event and > check if the MAC address is in the whitelist and if so replace > the FDB entry without the locked flag enabled, and thus open > the port for the device. > > This feature is known as MAC-Auth or MAC Authentication Bypass > (MAB) in Cisco terminology, where the full MAB concept involves > additional Cisco infrastructure for authorization. There is no > real authentication process, as the MAC address of the device > is the only input the authorization daemon, in the general > case, has to base the decision if to unlock the port or not. > > With this patch set, an implementation of the offloaded case is > supplied for the mv88e6xxx driver. When a packet ingresses on > a locked port, an ATU miss violation event will occur. When > handling such ATU miss violation interrupts, the MAC address of > the device is added to the FDB with a zero destination port > vector (DPV) and the MAC address is communicated through the > switchdev layer to the bridge, so that a FDB entry with the > locked flag enabled can be added. FWIW, we may have about a 30% - 70% split between switches that will signal ATU violations over a side band interrupt, like mv88e6xxx will, and the rest will likely signal such events via the proprietary tag format.
On ons, mar 16, 2022 at 17:18, Florian Fainelli <f.fainelli@gmail.com> wrote: > On 3/10/2022 6:23 AM, Hans Schultz wrote: >> This patch set extends the locked port feature for devices >> that are behind a locked port, but do not have the ability to >> authorize themselves as a supplicant using IEEE 802.1X. >> Such devices can be printers, meters or anything related to >> fixed installations. Instead of 802.1X authorization, devices >> can get access based on their MAC addresses being whitelisted. >> >> For an authorization daemon to detect that a device is trying >> to get access through a locked port, the bridge will add the >> MAC address of the device to the FDB with a locked flag to it. >> Thus the authorization daemon can catch the FDB add event and >> check if the MAC address is in the whitelist and if so replace >> the FDB entry without the locked flag enabled, and thus open >> the port for the device. >> >> This feature is known as MAC-Auth or MAC Authentication Bypass >> (MAB) in Cisco terminology, where the full MAB concept involves >> additional Cisco infrastructure for authorization. There is no >> real authentication process, as the MAC address of the device >> is the only input the authorization daemon, in the general >> case, has to base the decision if to unlock the port or not. >> >> With this patch set, an implementation of the offloaded case is >> supplied for the mv88e6xxx driver. When a packet ingresses on >> a locked port, an ATU miss violation event will occur. When >> handling such ATU miss violation interrupts, the MAC address of >> the device is added to the FDB with a zero destination port >> vector (DPV) and the MAC address is communicated through the >> switchdev layer to the bridge, so that a FDB entry with the >> locked flag enabled can be added. > > FWIW, we may have about a 30% - 70% split between switches that will > signal ATU violations over a side band interrupt, like mv88e6xxx will, > and the rest will likely signal such events via the proprietary tag > format. I guess that the proprietary tag scheme a scenario where the packet can be forwarded to the bridge module's ingress queue on the respective port? > -- > Florian
On Thu, Mar 17, 2022 at 09:29:10AM +0100, Hans Schultz wrote: > On ons, mar 16, 2022 at 17:18, Florian Fainelli <f.fainelli@gmail.com> wrote: > > On 3/10/2022 6:23 AM, Hans Schultz wrote: > >> This patch set extends the locked port feature for devices > >> that are behind a locked port, but do not have the ability to > >> authorize themselves as a supplicant using IEEE 802.1X. > >> Such devices can be printers, meters or anything related to > >> fixed installations. Instead of 802.1X authorization, devices > >> can get access based on their MAC addresses being whitelisted. > >> > >> For an authorization daemon to detect that a device is trying > >> to get access through a locked port, the bridge will add the > >> MAC address of the device to the FDB with a locked flag to it. > >> Thus the authorization daemon can catch the FDB add event and > >> check if the MAC address is in the whitelist and if so replace > >> the FDB entry without the locked flag enabled, and thus open > >> the port for the device. > >> > >> This feature is known as MAC-Auth or MAC Authentication Bypass > >> (MAB) in Cisco terminology, where the full MAB concept involves > >> additional Cisco infrastructure for authorization. There is no > >> real authentication process, as the MAC address of the device > >> is the only input the authorization daemon, in the general > >> case, has to base the decision if to unlock the port or not. > >> > >> With this patch set, an implementation of the offloaded case is > >> supplied for the mv88e6xxx driver. When a packet ingresses on > >> a locked port, an ATU miss violation event will occur. When > >> handling such ATU miss violation interrupts, the MAC address of > >> the device is added to the FDB with a zero destination port > >> vector (DPV) and the MAC address is communicated through the > >> switchdev layer to the bridge, so that a FDB entry with the > >> locked flag enabled can be added. > > > > FWIW, we may have about a 30% - 70% split between switches that will > > signal ATU violations over a side band interrupt, like mv88e6xxx will, > > and the rest will likely signal such events via the proprietary tag > > format. > > I guess that the proprietary tag scheme a scenario where the packet can > be forwarded to the bridge module's ingress queue on the respective > port? I'm not sure what you mean by forwarding to the bridge module's ingress queue. I expect that both cases of drivers to interact with the bridge in the exact same way, expect one of them calls call_switchdev_notifiers() from an interrupt context, and the other from NET_RX softirq context, from the tagging protocol driver (ok, maybe not directly, it depends upon whether we need rtnl_lock which sleeps, things like that). I might be just projecting based on what I know, but the way I interpret what Florian has said is by thinking of "learn frames" as described here: https://patchwork.kernel.org/project/netdevbpf/cover/20220209130538.533699-1-schultz.hans+netdev@gmail.com/#24734685 The advantage of signaling ATU misses or membership violations via learn frames is that you have a much wider toolbox of mitigations for denial of service. Instead of one ATU interrupt per packet, you have NAPI on the DSA master, interrupt coalescing, policers on the DSA master, rate limiting for learn frames in the switch...