1. 04 Nov, 2022 4 commits
    • Jiri Pirko's avatar
      net: devlink: convert devlink port type-specific pointers to union · 3830c571
      Jiri Pirko authored
      Instead of storing type_dev as a void pointer, convert it to union and
      use it to store either struct net_device or struct ib_device pointer.
      Signed-off-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3830c571
    • Jakub Kicinski's avatar
      Merge branch 'bridge-add-mac-authentication-bypass-mab-support' · 0884aaf3
      Jakub Kicinski authored
      Ido Schimmel says:
      
      ====================
      bridge: Add MAC Authentication Bypass (MAB) support
      
      Patch #1 adds MAB support in the bridge driver. See the commit message
      for motivation, design choices and implementation details.
      
      Patch #2 adds corresponding test cases.
      
      Follow-up patchsets will add offload support in mlxsw and mv88e6xxx.
      ====================
      
      Link: https://lore.kernel.org/r/20221101193922.2125323-1-idosch@nvidia.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0884aaf3
    • Hans J. Schultz's avatar
      selftests: forwarding: Add MAC Authentication Bypass (MAB) test cases · 4a331d34
      Hans J. Schultz authored
      Add four test cases to verify MAB functionality:
      
      * Verify that a locked FDB entry can be generated by the bridge,
        preventing a host from communicating via the bridge. Test that user
        space can clear the "locked" flag by replacing the entry, thereby
        authenticating the host and allowing it to communicate via the bridge.
      
      * Test that an entry cannot roam to a locked port, but that it can roam
        to an unlocked port.
      
      * Test that MAB can only be enabled on a port that is both locked and
        has learning enabled.
      
      * Test that locked FDB entries are flushed from a port when MAB is
        disabled.
      Signed-off-by: default avatarHans J. Schultz <netdev@kapio-technology.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4a331d34
    • Hans J. Schultz's avatar
      bridge: Add MAC Authentication Bypass (MAB) support · a35ec8e3
      Hans J. Schultz authored
      Hosts that support 802.1X authentication are able to authenticate
      themselves by exchanging EAPOL frames with an authenticator (Ethernet
      bridge, in this case) and an authentication server. Access to the
      network is only granted by the authenticator to successfully
      authenticated hosts.
      
      The above is implemented in the bridge using the "locked" bridge port
      option. When enabled, link-local frames (e.g., EAPOL) can be locally
      received by the bridge, but all other frames are dropped unless the host
      is authenticated. That is, unless the user space control plane installed
      an FDB entry according to which the source address of the frame is
      located behind the locked ingress port. The entry can be dynamic, in
      which case learning needs to be enabled so that the entry will be
      refreshed by incoming traffic.
      
      There are deployments in which not all the devices connected to the
      authenticator (the bridge) support 802.1X. Such devices can include
      printers and cameras. One option to support such deployments is to
      unlock the bridge ports connecting these devices, but a slightly more
      secure option is to use MAB. When MAB is enabled, the MAC address of the
      connected device is used as the user name and password for the
      authentication.
      
      For MAB to work, the user space control plane needs to be notified about
      MAC addresses that are trying to gain access so that they will be
      compared against an allow list. This can be implemented via the regular
      learning process with the sole difference that learned FDB entries are
      installed with a new "locked" flag indicating that the entry cannot be
      used to authenticate the device. The flag cannot be set by user space,
      but user space can clear the flag by replacing the entry, thereby
      authenticating the device.
      
      Locked FDB entries implement the following semantics with regards to
      roaming, aging and forwarding:
      
      1. Roaming: Locked FDB entries can roam to unlocked (authorized) ports,
         in which case the "locked" flag is cleared. FDB entries cannot roam
         to locked ports regardless of MAB being enabled or not. Therefore,
         locked FDB entries are only created if an FDB entry with the given {MAC,
         VID} does not already exist. This behavior prevents unauthenticated
         devices from disrupting traffic destined to already authenticated
         devices.
      
      2. Aging: Locked FDB entries age and refresh by incoming traffic like
         regular entries.
      
      3. Forwarding: Locked FDB entries forward traffic like regular entries.
         If user space detects an unauthorized MAC behind a locked port and
         wishes to prevent traffic with this MAC DA from reaching the host, it
         can do so using tc or a different mechanism.
      
      Enable the above behavior using a new bridge port option called "mab".
      It can only be enabled on a bridge port that is both locked and has
      learning enabled. Locked FDB entries are flushed from the port once MAB
      is disabled. A new option is added because there are pure 802.1X
      deployments that are not interested in notifications about locked FDB
      entries.
      Signed-off-by: default avatarHans J. Schultz <netdev@kapio-technology.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Acked-by: default avatarNikolay Aleksandrov <razor@blackwall.org>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a35ec8e3
  2. 03 Nov, 2022 33 commits
  3. 02 Nov, 2022 3 commits