From: Sabrina Dubroca <sd@queasysnail.net>
To: Subbaraya Sundeep Bhatta <sbhatta@marvell.com>
Cc: "ehakim@nvidia.com" <ehakim@nvidia.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"edumazet@google.com" <edumazet@google.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"leon@kernel.org" <leon@kernel.org>,
Sunil Kovvuri Goutham <sgoutham@marvell.com>,
Naveen Mamindlapalli <naveenm@marvell.com>,
atenart@kernel.org
Subject: Re: [PATCH net-next v5 5/5] macsec: Don't rely solely on the dst MAC address to identify destination MACsec device
Date: Tue, 18 Apr 2023 12:48:13 +0200 [thread overview]
Message-ID: <ZD51bbwHzYGxL3F3@hog> (raw)
In-Reply-To: <CO1PR18MB4666A6E343DBB5A1CCD005D4A1999@CO1PR18MB4666.namprd18.prod.outlook.com>
2023-04-14, 06:32:28 +0000, Subbaraya Sundeep Bhatta wrote:
> Hi,
>
> >-----Original Message-----
> >From: Emeel Hakim <ehakim@nvidia.com> <ehakim@nvidia.com>
> >Sent: Thursday, April 13, 2023 4:26 PM
> >To: davem@davemloft.net; kuba@kernel.org; pabeni@redhat.com;
> >edumazet@google.com; sd@queasysnail.net
> >Cc: netdev@vger.kernel.org; leon@kernel.org; Emeel Hakim
> ><ehakim@nvidia.com>
> >Subject: [PATCH net-next v5 5/5] macsec: Don't rely solely on the dst MAC
> >address to identify destination MACsec device
> >
> >Offloading device drivers will mark offloaded MACsec SKBs with the
> >corresponding SCI in the skb_metadata_dst so the macsec rx handler will know to
> >which interface to divert those skbs, in case of a marked skb and a mismatch on
> >the dst MAC address, divert the skb to the macsec net_device where the macsec
> >rx_handler will be called to consider cases where relying solely on the dst MAC
> >address is insufficient.
> >
> >One such instance is when using MACsec with a VLAN as an inner header, where
> >the packet structure is ETHERNET | SECTAG | VLAN.
> >In such a scenario, the dst MAC address in the ethernet header will correspond to
> >the VLAN MAC address, resulting in a mismatch.
> >
>
> I did below commands:
> ifconfig eth2 up
> ip link add link eth2 macsec0 type macsec sci cacbcd4142430002
> ifconfig macsec0 hw ether ca:cb:cd:41:42:43
> ip macsec offload macsec0 mac
> ifconfig macsec0 up
> ip macsec add macsec0 tx sa 0 on pn 5 key 02 22222222222222222222222222222222
> ip macsec add macsec0 rx sci cacbcd2122230001
> ip macsec add macsec0 rx sci cacbcd2122230001 sa 0 pn 5 on key 01 11111111111111111111111111111111
> ip link add link macsec0 vlan0 type vlan id 2
>
> ifconfig vlan0 hw ether ca:cb:cd:21:22:23
> ifconfig vlan0 up
> [ 7106.072451] device macsec0 entered promiscuous mode
> [ 7106.077330] device eth2 entered promiscuous mode
>
> macsec0 entered promisc mode when upper_dev mac address is not equal to its mac.
> I think we should check if macsec device is in promisc mode instead of omitting mac address compare.
> Also all drivers/hardware do not support md_dst->type == METADATA_MACSEC
Is there a good reason to not make all drivers use metadata? It seems
to me it would be cleaner than trying to guess where a packet belongs
once it reaches the macsec core.
--
Sabrina
next prev parent reply other threads:[~2023-04-18 10:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 10:56 [PATCH net-next v5 0/5] Support MACsec VLAN Emeel Hakim
2023-04-13 10:56 ` [PATCH net-next v5 1/5] vlan: Add MACsec offload operations for VLAN interface Emeel Hakim
2023-04-13 10:56 ` [PATCH net-next v5 2/5] net/mlx5: Enable MACsec offload feature " Emeel Hakim
2023-04-13 10:56 ` [PATCH net-next v5 3/5] net/mlx5: Support MACsec over VLAN Emeel Hakim
2023-04-13 10:56 ` [PATCH net-next v5 4/5] net/mlx5: Consider VLAN interface in MACsec TX steering rules Emeel Hakim
2023-04-13 10:56 ` [PATCH net-next v5 5/5] macsec: Don't rely solely on the dst MAC address to identify destination MACsec device Emeel Hakim
2023-04-14 6:32 ` Subbaraya Sundeep Bhatta
2023-04-16 12:14 ` Emeel Hakim
2023-04-17 17:37 ` Subbaraya Sundeep Bhatta
2023-04-18 7:05 ` Emeel Hakim
2023-04-18 10:48 ` Sabrina Dubroca [this message]
2023-04-18 14:35 ` Subbaraya Sundeep Bhatta
2023-04-14 15:00 ` Jakub Kicinski
2023-04-16 12:18 ` Emeel Hakim
2023-04-17 18:04 ` Jakub Kicinski
2023-04-13 22:48 ` [PATCH net-next v5 0/5] Support MACsec VLAN Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZD51bbwHzYGxL3F3@hog \
--to=sd@queasysnail.net \
--cc=atenart@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=ehakim@nvidia.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=naveenm@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sbhatta@marvell.com \
--cc=sgoutham@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.