Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Wed, 23 Feb 2022 08:20:24 -0800
From:   Jakub Kicinski <kuba@kernel.org>
To:     Hans Schultz <schultz.hans@gmail.com>
Cc:     davem@davemloft.net, netdev@vger.kernel.org,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        Roopa Prabhu <roopa@nvidia.com>,
        Nikolay Aleksandrov <nikolay@nvidia.com>,
        Shuah Khan <shuah@kernel.org>,
        Stephen Suryaputra <ssuryaextr@gmail.com>,
        David Ahern <dsahern@kernel.org>,
        Ido Schimmel <idosch@nvidia.com>,
        Petr Machata <petrm@nvidia.com>,
        Amit Cohen <amcohen@nvidia.com>,
        Po-Hsu Lin <po-hsu.lin@canonical.com>,
        Baowen Zheng <baowen.zheng@corigine.com>,
        linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org,
        linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next v4 0/5] Add support for locked bridge ports
 (for 802.1X)
Message-ID: <20220223082024.6ab51265@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
In-Reply-To: <86y222vuuc.fsf@gmail.com>
References: <20220222132818.1180786-1-schultz.hans+netdev@gmail.com>
        <20220222111523.030ab13d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
        <86y222vuuc.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 23 Feb 2022 09:40:59 +0100 Hans Schultz wrote:
> > You still haven't answer my question. Is the data plane clear text in
> > the deployment you describe?  
> 
> Sorry, I didn't understand your question in the first instance. So as
> 802.1X is only about authentication/authorization, the port when opened
> for a host is like any other switch port and thus communication is in
> the clear.

Alright, thanks for clarifying!

> I have not looked much into macsec (but know ipsec), and that is a
> crypto (key) based connection mechanism, but that is a totally different
> ballgame, and I think it would for most practical cases require hardware 
> encryption.