lkml.org 
[lkml]   [2022]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH net-next v4 0/5] Add support for locked bridge ports (for 802.1X)
    On Tue, 22 Feb 2022 14:28:13 +0100 Hans Schultz wrote:
    > This series starts by adding support for SA filtering to the bridge,
    > which is then allowed to be offloaded to switchdev devices. Furthermore
    > an offloading implementation is supplied for the mv88e6xxx driver.
    >
    > Public Local Area Networks are often deployed such that there is a
    > risk of unauthorized or unattended clients getting access to the LAN.
    > To prevent such access we introduce SA filtering, such that ports
    > designated as secure ports are set in locked mode, so that only
    > authorized source MAC addresses are given access by adding them to
    > the bridges forwarding database. Incoming packets with source MAC
    > addresses that are not in the forwarding database of the bridge are
    > discarded. It is then the task of user space daemons to populate the
    > bridge's forwarding database with static entries of authorized entities.
    >
    > The most common approach is to use the IEEE 802.1X protocol to take
    > care of the authorization of allowed users to gain access by opening
    > for the source address of the authorized host.
    >
    > With the current use of the bridge parameter in hostapd, there is
    > a limitation in using this for IEEE 802.1X port authentication. It
    > depends on hostapd attaching the port on which it has a successful
    > authentication to the bridge, but that only allows for a single
    > authentication per port. This patch set allows for the use of
    > IEEE 802.1X port authentication in a more general network context with
    > multiple 802.1X aware hosts behind a single port as depicted, which is
    > a commonly used commercial use-case, as it is only the number of
    > available entries in the forwarding database that limits the number of
    > authenticated clients.
    >
    > +--------------------------------+
    > | |
    > | Bridge/Authenticator |
    > | |
    > +-------------+------------------+
    > 802.1X port |
    > |
    > |
    > +------+-------+
    > | |
    > | Hub/Switch |
    > | |
    > +-+----------+-+
    > | |
    > +--+--+ +--+--+
    > | | | |
    > Hosts | a | | b | . . .
    > | | | |
    > +-----+ +-----+
    >
    > The 802.1X standard involves three different components, a Supplicant
    > (Host), an Authenticator (Network Access Point) and an Authentication
    > Server which is typically a Radius server. This patch set thus enables
    > the bridge module together with an authenticator application to serve
    > as an Authenticator on designated ports.
    >
    >
    > For the bridge to become an IEEE 802.1X Authenticator, a solution using
    > hostapd with the bridge driver can be found at
    > https://github.com/westermo/hostapd/tree/bridge_driver .
    >
    >
    > The relevant components work transparently in relation to if it is the
    > bridge module or the offloaded switchcore case that is in use.

    You still haven't answer my question. Is the data plane clear text in
    the deployment you describe?

    \
     
     \ /
      Last update: 2022-02-22 20:15    [W:2.783 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site