netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).