Re: [PATCH net-next v1 1/1] net: bridge: ensure that link-local traffic cannot unlock a locked port
On Thu, Jun 30, 2022 at 01:16:34PM +0200, Hans Schultz wrote:
This patch is related to the patch set "Add support for locked bridge ports (for 802.1X)" Link: https://lore.kernel.org/netdev/20220223101650.1212814-1-schultz.hans+netdev@...
This patch makes the locked port feature work with learning turned on, which is enabled with the command:
bridge link set dev DEV learning on
Without this patch, link local traffic (01:80:c2) like EAPOL packets will create a fdb entry when ingressing on a locked port with learning turned on, thus unintentionally opening up the port for traffic for the said MAC.
Some switchcore features like Mac-Auth and refreshing of FDB entries, require learning enables on some switchcores, f.ex. the mv88e6xxx family. Other features may apply too.
Since many switchcores trap or mirror various multicast packets to the CPU, link local traffic will unintentionally unlock the port for the SA mac in question unless prevented by this patch.
Why not just teach hostapd to do:
echo 1 > /sys/class/net/br0/bridge/no_linklocal_learn
?
One question though... wouldn't it be an issue that the mentioned option setting is bridge wide, while the patch applies a per-port effect?
On Thu, Jun 30, 2022 at 1:38 PM Ido Schimmel idosch@nvidia.com wrote:
On Thu, Jun 30, 2022 at 01:16:34PM +0200, Hans Schultz wrote:
This patch is related to the patch set "Add support for locked bridge ports (for 802.1X)" Link: https://lore.kernel.org/netdev/20220223101650.1212814-1-schultz.hans+netdev@...
This patch makes the locked port feature work with learning turned on, which is enabled with the command:
bridge link set dev DEV learning on
Without this patch, link local traffic (01:80:c2) like EAPOL packets will create a fdb entry when ingressing on a locked port with learning turned on, thus unintentionally opening up the port for traffic for the said MAC.
Some switchcore features like Mac-Auth and refreshing of FDB entries, require learning enables on some switchcores, f.ex. the mv88e6xxx family. Other features may apply too.
Since many switchcores trap or mirror various multicast packets to the CPU, link local traffic will unintentionally unlock the port for the SA mac in question unless prevented by this patch.
Why not just teach hostapd to do:
echo 1 > /sys/class/net/br0/bridge/no_linklocal_learn
?
On Fri, Jul 01, 2022 at 09:47:24AM +0200, Hans S wrote:
One question though... wouldn't it be an issue that the mentioned option setting is bridge wide, while the patch applies a per-port effect?
Why would it be an issue? To me, the bigger issue is changing the semantics of "locked" in 5.20 compared to previous kernels.
What is even the use case for enabling learning when the port is locked? In current kernels, only SAs from link local traffic will be learned, but with this patch, nothing will be learned. So why enable learning in the first place? As an administrator, I mark a port as "locked" so that only traffic with SAs that I configured will be allowed. Enabling learning when the port is locked seems to defeat the purpose?
It would be helpful to explain why mv88e6xxx needs to have learning enabled in the first place. IIUC, the software bridge can function correctly with learning disabled. It might be better to solve this in mv88e6xxx so that user space would not need to enable learning on the SW bridge and then work around issues caused by it such as learning from link local traffic.
On Fri, Jul 01, 2022 at 04:51:44PM +0300, Ido Schimmel wrote:
On Fri, Jul 01, 2022 at 09:47:24AM +0200, Hans S wrote:
One question though... wouldn't it be an issue that the mentioned option setting is bridge wide, while the patch applies a per-port effect?
Why would it be an issue? To me, the bigger issue is changing the semantics of "locked" in 5.20 compared to previous kernels.
What is even the use case for enabling learning when the port is locked? In current kernels, only SAs from link local traffic will be learned, but with this patch, nothing will be learned. So why enable learning in the first place? As an administrator, I mark a port as "locked" so that only traffic with SAs that I configured will be allowed. Enabling learning when the port is locked seems to defeat the purpose?
I think if learning on a locked port doesn't make sense, the bridge should just reject that configuration.
On Fri, Jul 01, 2022 at 06:27:00PM +0300, Vladimir Oltean wrote:
On Fri, Jul 01, 2022 at 04:51:44PM +0300, Ido Schimmel wrote:
On Fri, Jul 01, 2022 at 09:47:24AM +0200, Hans S wrote:
One question though... wouldn't it be an issue that the mentioned option setting is bridge wide, while the patch applies a per-port effect?
Why would it be an issue? To me, the bigger issue is changing the semantics of "locked" in 5.20 compared to previous kernels.
What is even the use case for enabling learning when the port is locked? In current kernels, only SAs from link local traffic will be learned, but with this patch, nothing will be learned. So why enable learning in the first place? As an administrator, I mark a port as "locked" so that only traffic with SAs that I configured will be allowed. Enabling learning when the port is locked seems to defeat the purpose?
I think if learning on a locked port doesn't make sense, the bridge should just reject that configuration.
I tend to agree... Let's wait for Hans to explain why learning needs to be enabled on mv88e6xxx and see how we handle it in mv88e6xxx and the bridge.
There is several issues when learning is turned off with the mv88e6xxx driver:
Mac-Auth requires learning turned on, otherwise there will be no miss violation interrupts afair. Refreshing of ATU entries does not work with learning turn off, as the PAV is set to zero when learning is turned off. This then further eliminates the use of the HoldAt1 feature and age-out interrupts.
With dynamic ATU entries (an upcoming patch set), an authorized unit gets a dynamic ATU entry, and if it goes quiet for 5 minutes, it's entry will age out and thus get removed. That also solves the port relocation issue as if a device relocates to another port it will be able to get access again after 5 minutes.
On Fri, Jul 1, 2022 at 3:51 PM Ido Schimmel idosch@nvidia.com wrote:
On Fri, Jul 01, 2022 at 09:47:24AM +0200, Hans S wrote:
One question though... wouldn't it be an issue that the mentioned option setting is bridge wide, while the patch applies a per-port effect?
Why would it be an issue? To me, the bigger issue is changing the semantics of "locked" in 5.20 compared to previous kernels.
What is even the use case for enabling learning when the port is locked? In current kernels, only SAs from link local traffic will be learned, but with this patch, nothing will be learned. So why enable learning in the first place? As an administrator, I mark a port as "locked" so that only traffic with SAs that I configured will be allowed. Enabling learning when the port is locked seems to defeat the purpose?
It would be helpful to explain why mv88e6xxx needs to have learning enabled in the first place. IIUC, the software bridge can function correctly with learning disabled. It might be better to solve this in mv88e6xxx so that user space would not need to enable learning on the SW bridge and then work around issues caused by it such as learning from link local traffic.
On Fri, Jul 01, 2022 at 06:07:10PM +0200, Hans S wrote:
There is several issues when learning is turned off with the mv88e6xxx driver:
Please don't top-post...
Mac-Auth requires learning turned on, otherwise there will be no miss violation interrupts afair. Refreshing of ATU entries does not work with learning turn off, as the PAV is set to zero when learning is turned off. This then further eliminates the use of the HoldAt1 feature and age-out interrupts.
With dynamic ATU entries (an upcoming patch set), an authorized unit gets a dynamic ATU entry, and if it goes quiet for 5 minutes, it's entry will age out and thus get removed. That also solves the port relocation issue as if a device relocates to another port it will be able to get access again after 5 minutes.
You assume I'm familiar with mv88e6xxx, when in fact I'm not. Here is what I think you are saying:
1. When a port is locked and a packet is received with a SA that is not in the FDB, it will only generate a miss violation if learning is enabled. In which case, you will notify the bridge driver about this entry as externally learned and locked entry.
2. When a port is locked and a packet is received with a SA that matches a different port, it will be dropped regardless if learning is enabled or not.
3. From the above I conclude that the HW will not auto-populate its FDB when a port is locked.
4. FDB entries that point to a port that does not have learning enabled are not subject to ageing (why?).
Assuming the above is correct, in order for mv88e6xxx to work correctly, it needs to enable learning on all locked ports, but it should happen regardless of the bridge driver learning configuration let alone impose any limitations on it. In fact, hostapd must disable learning for all locked ports.
On Fri, Jul 1, 2022 at 7:00 PM Ido Schimmel idosch@nvidia.com wrote:
On Fri, Jul 01, 2022 at 06:07:10PM +0200, Hans S wrote:
There is several issues when learning is turned off with the mv88e6xxx driver:
Please don't top-post...
Sorry, I am using gmails own web interface for a short while now as my other options are not supported anymore by Google (not secure apps)
Mac-Auth requires learning turned on, otherwise there will be no miss violation interrupts afair. Refreshing of ATU entries does not work with learning turn off, as the PAV is set to zero when learning is turned off. This then further eliminates the use of the HoldAt1 feature and age-out interrupts.
With dynamic ATU entries (an upcoming patch set), an authorized unit gets a dynamic ATU entry, and if it goes quiet for 5 minutes, it's entry will age out and thus get removed. That also solves the port relocation issue as if a device relocates to another port it will be able to get access again after 5 minutes.
You assume I'm familiar with mv88e6xxx, when in fact I'm not. Here is what I think you are saying:
- When a port is locked and a packet is received with a SA that is not
in the FDB, it will only generate a miss violation if learning is enabled. In which case, you will notify the bridge driver about this entry as externally learned and locked entry.
Right.
- When a port is locked and a packet is received with a SA that matches
a different port, it will be dropped regardless if learning is enabled or not.
I would think so.
- From the above I conclude that the HW will not auto-populate its FDB
when a port is locked.
Right, and it should not as the locked port feature is basically CPU controlled learning. (yes it is an irony to have CPU controlled learning and learning turned on, but that is just how it is with the mv88e6xxx series :-) )
- FDB entries that point to a port that does not have learning enabled
are not subject to ageing (why?).
Sorry if I said so. Dynamic ATU entries will age I am sure, but they will not refresh unless there is a match between the ingress port and the Port Association Vector (PAV). But an age out violation will not occur, and the HoldAt1 (entries age from 7 -> 0) feature will not work either as it is related to the refresh mechanism.
Assuming the above is correct, in order for mv88e6xxx to work correctly, it needs to enable learning on all locked ports, but it should happen regardless of the bridge driver learning configuration let alone impose any limitations on it. In fact, hostapd must disable learning for all locked ports.
To have hardware induced refreshing I would say learning should be on also for 802.1X (hostapd). This relies of course on user added dynamic ATU entries, which is what my follow-up patch set is about. Besides it is perfectly feasible to have both 802.1X and Mac-Auth on the same port.
On Fri, Jul 01, 2022 at 09:17:27PM +0200, Hans S wrote:
On Fri, Jul 1, 2022 at 7:00 PM Ido Schimmel idosch@nvidia.com wrote:
On Fri, Jul 01, 2022 at 06:07:10PM +0200, Hans S wrote:
There is several issues when learning is turned off with the mv88e6xxx driver:
Please don't top-post...
Sorry, I am using gmails own web interface for a short while now as my other options are not supported anymore by Google (not secure apps)
Mac-Auth requires learning turned on, otherwise there will be no miss violation interrupts afair. Refreshing of ATU entries does not work with learning turn off, as the PAV is set to zero when learning is turned off. This then further eliminates the use of the HoldAt1 feature and age-out interrupts.
With dynamic ATU entries (an upcoming patch set), an authorized unit gets a dynamic ATU entry, and if it goes quiet for 5 minutes, it's entry will age out and thus get removed. That also solves the port relocation issue as if a device relocates to another port it will be able to get access again after 5 minutes.
You assume I'm familiar with mv88e6xxx, when in fact I'm not. Here is what I think you are saying:
- When a port is locked and a packet is received with a SA that is not
in the FDB, it will only generate a miss violation if learning is enabled. In which case, you will notify the bridge driver about this entry as externally learned and locked entry.
Right.
- When a port is locked and a packet is received with a SA that matches
a different port, it will be dropped regardless if learning is enabled or not.
I would think so.
- From the above I conclude that the HW will not auto-populate its FDB
when a port is locked.
Right, and it should not as the locked port feature is basically CPU controlled learning. (yes it is an irony to have CPU controlled learning and learning turned on, but that is just how it is with the mv88e6xxx series :-) )
- FDB entries that point to a port that does not have learning enabled
are not subject to ageing (why?).
Sorry if I said so. Dynamic ATU entries will age I am sure, but they will not refresh unless there is a match between the ingress port and the Port Association Vector (PAV). But an age out violation will not occur, and the HoldAt1 (entries age from 7 -> 0) feature will not work either as it is related to the refresh mechanism.
Assuming the above is correct, in order for mv88e6xxx to work correctly, it needs to enable learning on all locked ports, but it should happen regardless of the bridge driver learning configuration let alone impose any limitations on it. In fact, hostapd must disable learning for all locked ports.
To have hardware induced refreshing I would say learning should be on also for 802.1X (hostapd). This relies of course on user added dynamic ATU entries, which is what my follow-up patch set is about. Besides it is perfectly feasible to have both 802.1X and Mac-Auth on the same port.
IIUC, with mv88e6xxx, when the port is locked and learning is disabled:
1. You do not get miss violation interrupts. Meaning, you can't report 'locked' entries to the bridge driver.
2. You do not get aged-out interrupts. Meaning, you can't tell the bridge driver to remove aged-out entries.
My point is that this should happen regardless if learning is enabled on the bridge driver or not. Just make sure it is always enabled in mv88e6xxx when the port is locked. Learning in the bridge driver itself can be off, thereby eliminating the need to disable learning from link-local packets.
IIUC, with mv88e6xxx, when the port is locked and learning is disabled:
- You do not get miss violation interrupts. Meaning, you can't report
'locked' entries to the bridge driver.
- You do not get aged-out interrupts. Meaning, you can't tell the
bridge driver to remove aged-out entries.
My point is that this should happen regardless if learning is enabled on the bridge driver or not. Just make sure it is always enabled in mv88e6xxx when the port is locked. Learning in the bridge driver itself can be off, thereby eliminating the need to disable learning from link-local packets.
So you suggest that we enable learning in the driver when locking the port and document that learning should be turned off from user space before locking the port?
On Mon, Jul 04, 2022 at 09:54:31AM +0200, Hans S wrote:
IIUC, with mv88e6xxx, when the port is locked and learning is disabled:
- You do not get miss violation interrupts. Meaning, you can't report
'locked' entries to the bridge driver.
- You do not get aged-out interrupts. Meaning, you can't tell the
bridge driver to remove aged-out entries.
My point is that this should happen regardless if learning is enabled on the bridge driver or not. Just make sure it is always enabled in mv88e6xxx when the port is locked. Learning in the bridge driver itself can be off, thereby eliminating the need to disable learning from link-local packets.
So you suggest that we enable learning in the driver when locking the port and document that learning should be turned off from user space before locking the port?
Yes. Ideally, the bridge driver would reject configurations where learning is enabled and the port is locked, but it might be too late for that. It would be good to add a note in the man page that learning should be disabled when the port is locked to avoid "unlocking" the port by accident.
On Mon, Jul 4, 2022 at 1:00 PM Ido Schimmel idosch@nvidia.com wrote:
On Mon, Jul 04, 2022 at 09:54:31AM +0200, Hans S wrote:
IIUC, with mv88e6xxx, when the port is locked and learning is disabled:
- You do not get miss violation interrupts. Meaning, you can't report
'locked' entries to the bridge driver.
- You do not get aged-out interrupts. Meaning, you can't tell the
bridge driver to remove aged-out entries.
My point is that this should happen regardless if learning is enabled on the bridge driver or not. Just make sure it is always enabled in mv88e6xxx when the port is locked. Learning in the bridge driver itself can be off, thereby eliminating the need to disable learning from link-local packets.
So you suggest that we enable learning in the driver when locking the port and document that learning should be turned off from user space before locking the port?
Yes. Ideally, the bridge driver would reject configurations where learning is enabled and the port is locked, but it might be too late for that. It would be good to add a note in the man page that learning should be disabled when the port is locked to avoid "unlocking" the port by accident.
Well you cannot unlock the port by either enabling or disabling learning after the port is locked, but Mac-Auth and refreshing might not work. I clarify just so that no-one gets confused.
I can do so that the driver returns -EINVAL if learning is on when locking the port, but that would of course only be for mv88e6xxx...
On Mon, Jul 04, 2022 at 04:36:12PM +0200, Hans S wrote:
On Mon, Jul 4, 2022 at 1:00 PM Ido Schimmel idosch@nvidia.com wrote:
On Mon, Jul 04, 2022 at 09:54:31AM +0200, Hans S wrote:
IIUC, with mv88e6xxx, when the port is locked and learning is disabled:
- You do not get miss violation interrupts. Meaning, you can't report
'locked' entries to the bridge driver.
- You do not get aged-out interrupts. Meaning, you can't tell the
bridge driver to remove aged-out entries.
My point is that this should happen regardless if learning is enabled on the bridge driver or not. Just make sure it is always enabled in mv88e6xxx when the port is locked. Learning in the bridge driver itself can be off, thereby eliminating the need to disable learning from link-local packets.
So you suggest that we enable learning in the driver when locking the port and document that learning should be turned off from user space before locking the port?
Yes. Ideally, the bridge driver would reject configurations where learning is enabled and the port is locked, but it might be too late for that. It would be good to add a note in the man page that learning should be disabled when the port is locked to avoid "unlocking" the port by accident.
Well you cannot unlock the port by either enabling or disabling learning after the port is locked, but Mac-Auth and refreshing might not work. I clarify just so that no-one gets confused.
I was referring to the fact that if learning is enabled, a host can populate the FDB with whatever MAC it wants by crafting a link-local packet with this MAC as SA. Subsequent packets with this MAC as SA will pass the locking check in the bridge driver.
I can do so that the driver returns -EINVAL if learning is on when locking the port, but that would of course only be for mv88e6xxx...
Working around this issue in the mv88e6xxx driver is the correct thing to do, IMO. We avoid leaking this implementation detail (i.e., forcing learning to be enabled) to user space, which in turn helps us avoid working around issues created by it (this patch, for example).
Hi Hans,
On Fri, Jul 01, 2022 at 06:07:10PM +0200, Hans S wrote:
On Fri, Jul 1, 2022 at 3:51 PM Ido Schimmel idosch@nvidia.com wrote:
On Fri, Jul 01, 2022 at 09:47:24AM +0200, Hans S wrote:
One question though... wouldn't it be an issue that the mentioned option setting is bridge wide, while the patch applies a per-port effect?
Why would it be an issue? To me, the bigger issue is changing the semantics of "locked" in 5.20 compared to previous kernels.
What is even the use case for enabling learning when the port is locked? In current kernels, only SAs from link local traffic will be learned, but with this patch, nothing will be learned. So why enable learning in the first place? As an administrator, I mark a port as "locked" so that only traffic with SAs that I configured will be allowed. Enabling learning when the port is locked seems to defeat the purpose?
It would be helpful to explain why mv88e6xxx needs to have learning enabled in the first place. IIUC, the software bridge can function correctly with learning disabled. It might be better to solve this in mv88e6xxx so that user space would not need to enable learning on the SW bridge and then work around issues caused by it such as learning from link local traffic.
There is several issues when learning is turned off with the mv88e6xxx driver:
Mac-Auth requires learning turned on, otherwise there will be no miss violation interrupts afair. Refreshing of ATU entries does not work with learning turn off, as the PAV is set to zero when learning is turned off. This then further eliminates the use of the HoldAt1 feature and age-out interrupts.
With dynamic ATU entries (an upcoming patch set), an authorized unit gets a dynamic ATU entry, and if it goes quiet for 5 minutes, it's entry will age out and thus get removed. That also solves the port relocation issue as if a device relocates to another port it will be able to get access again after 5 minutes.
I think the discussion derailed at this exact point, when you responded that "Mac-Auth requires learning turned on".
What precise feature do you describe when you say "Mac-Auth"? Do you mean 802.1X MAC-based authentication in general (where data plane packets on a locked port are dropped unless their MAC SA is in the FDB, and populating the FDB is *entirely* up to user space, there aren't any locked FDB entries on locked ports), or MAC authentication *bypass* (where the kernel auto-adds locked FDB entries on locked ports)?
I *think* it's just the bypass that requires learning in mv88e6xxx. But the bypass (the feature where the kernel auto-adds locked FDB entries on locked ports) doesn't exist in net-next.
Here, what happens is that a locked port learns the MAC SA from the traffic it didn't drop, i.e. link-local. In other words, the bridge behaves as expected and instructed: +locked +learning will cause just that. It's the administrator's fault for not disabling learning. It's also the mv88e6xxx driver's fault for not validating the "locked" + "learning" brport flag *combination* until it properly supports "+locked +learning" (the feature you are currently working on).
I'm still confused why we don't just say that "+locked -learning" means plain 802.1X, "+locked +learning" means MAB where we learn locked FDB entries.
On Sun, Jul 17, 2022 at 04:46:10PM +0300, Vladimir Oltean wrote:
Here, what happens is that a locked port learns the MAC SA from the traffic it didn't drop, i.e. link-local. In other words, the bridge behaves as expected and instructed: +locked +learning will cause just that. It's the administrator's fault for not disabling learning. It's also the mv88e6xxx driver's fault for not validating the "locked" + "learning" brport flag *combination* until it properly supports "+locked +learning" (the feature you are currently working on).
I'm still confused why we don't just say that "+locked -learning" means plain 802.1X, "+locked +learning" means MAB where we learn locked FDB entries.
Or is it the problem that a "+locked +learning" bridge port will learn MAC SA from link-local traffic, but it will create FDB entries without the locked flag while doing so? The mv88e6xxx driver should react to the 'locked' flag from both directions (ADD_TO_DEVICE too, not just ADD_TO_BRIDGE).
On Sun, Jul 17, 2022 at 4:03 PM Vladimir Oltean olteanv@gmail.com wrote:
On Sun, Jul 17, 2022 at 04:46:10PM +0300, Vladimir Oltean wrote:
Here, what happens is that a locked port learns the MAC SA from the traffic it didn't drop, i.e. link-local. In other words, the bridge behaves as expected and instructed: +locked +learning will cause just that. It's the administrator's fault for not disabling learning. It's also the mv88e6xxx driver's fault for not validating the "locked" + "learning" brport flag *combination* until it properly supports "+locked +learning" (the feature you are currently working on).
I'm still confused why we don't just say that "+locked -learning" means plain 802.1X, "+locked +learning" means MAB where we learn locked FDB entries.
Or is it the problem that a "+locked +learning" bridge port will learn MAC SA from link-local traffic, but it will create FDB entries without the locked flag while doing so? The mv88e6xxx driver should react to the 'locked' flag from both directions (ADD_TO_DEVICE too, not just ADD_TO_BRIDGE).
Yes, it creates an FDB entry in the bridge without the locked flag set, and sends an ADD_TO_DEVICE notice with it. And furthermore link-local packets include of course EAPOL packets, so that's why +learning is a problem.
On Sun, Jul 17, 2022 at 06:22:57PM +0200, Hans S wrote:
On Sun, Jul 17, 2022 at 4:03 PM Vladimir Oltean olteanv@gmail.com wrote:
On Sun, Jul 17, 2022 at 04:46:10PM +0300, Vladimir Oltean wrote:
Here, what happens is that a locked port learns the MAC SA from the traffic it didn't drop, i.e. link-local. In other words, the bridge behaves as expected and instructed: +locked +learning will cause just that. It's the administrator's fault for not disabling learning. It's also the mv88e6xxx driver's fault for not validating the "locked" + "learning" brport flag *combination* until it properly supports "+locked +learning" (the feature you are currently working on).
I'm still confused why we don't just say that "+locked -learning" means plain 802.1X, "+locked +learning" means MAB where we learn locked FDB entries.
Or is it the problem that a "+locked +learning" bridge port will learn MAC SA from link-local traffic, but it will create FDB entries without the locked flag while doing so? The mv88e6xxx driver should react to the 'locked' flag from both directions (ADD_TO_DEVICE too, not just ADD_TO_BRIDGE).
Yes, it creates an FDB entry in the bridge without the locked flag set, and sends an ADD_TO_DEVICE notice with it. And furthermore link-local packets include of course EAPOL packets, so that's why +learning is a problem.
So if we fix that, and make the dynamically learned FDB entry be locked because the port is locked (and offload them correctly in mv88e6xxx), what would be the problem, exactly? The +learning is what would allow these locked FDB entries to be created, and would allow the MAB to work. User space may still decide to not authorize this address, and it will remain locked.
On Sun, Jul 17, 2022 at 8:38 PM Vladimir Oltean olteanv@gmail.com wrote:
On Sun, Jul 17, 2022 at 06:22:57PM +0200, Hans S wrote:
On Sun, Jul 17, 2022 at 4:03 PM Vladimir Oltean olteanv@gmail.com wrote:
Yes, it creates an FDB entry in the bridge without the locked flag set, and sends an ADD_TO_DEVICE notice with it. And furthermore link-local packets include of course EAPOL packets, so that's why +learning is a problem.
So if we fix that, and make the dynamically learned FDB entry be locked because the port is locked (and offload them correctly in mv88e6xxx), what would be the problem, exactly? The +learning is what would allow these locked FDB entries to be created, and would allow the MAB to work. User space may still decide to not authorize this address, and it will remain locked.
The alternative is to have -learning and let the driver only enable the PAV to admit the interrupts, which is what this implementation does. The plus side of this is that having EAPOL packets triggering locked entries from the bridge side is not really so nice IMHO. In a situation with 802.1X and MAB on the same port, there will then not be any triggering of MAB when initiating the 802.1X session, which I think is the best option. It then also lessens the confusion between hostapd and the daemon that handles MAB sessions.
On Sun, Jul 17, 2022 at 09:20:57PM +0200, Hans S wrote:
On Sun, Jul 17, 2022 at 8:38 PM Vladimir Oltean olteanv@gmail.com wrote:
On Sun, Jul 17, 2022 at 06:22:57PM +0200, Hans S wrote:
On Sun, Jul 17, 2022 at 4:03 PM Vladimir Oltean olteanv@gmail.com wrote:
Yes, it creates an FDB entry in the bridge without the locked flag set, and sends an ADD_TO_DEVICE notice with it. And furthermore link-local packets include of course EAPOL packets, so that's why +learning is a problem.
So if we fix that, and make the dynamically learned FDB entry be locked because the port is locked (and offload them correctly in mv88e6xxx), what would be the problem, exactly? The +learning is what would allow these locked FDB entries to be created, and would allow the MAB to work. User space may still decide to not authorize this address, and it will remain locked.
The alternative is to have -learning and let the driver only enable the PAV to admit the interrupts, which is what this implementation does. The plus side of this is that having EAPOL packets triggering locked entries from the bridge side is not really so nice IMHO. In a situation with 802.1X and MAB on the same port, there will then not be any triggering of MAB when initiating the 802.1X session, which I think is the best option. It then also lessens the confusion between hostapd and the daemon that handles MAB sessions.
Why is it "not really so nice" to "trigger MAB" (in fact only to learn a locked entry on a locked port) when initiating the 802.1X session? You can disable link-local learning via the bridge option if you're really bothered by that. When you have MAB enabled on an 802.1X port, I think it's reasonable to expect that there will be some locked entries which user space won't ever unlock via MAB. If those entries happen to be created as a side effect of the normal EAPOL authentication process, I don't exactly see where is the functional problem. This shouldn't block EAPOL from proceeding any further, because this protocol uses link-local packets which are classified as control traffic, and that isn't subject to FDB lookups but rather always trapped to CPU, so locked or not, it should still be received.
I'm only pointing out the obvious here, we need an opt in for MAB, and the implemented behavior I've seen here kind of points to mapping this to "+learning +locked", where the learning process creates locked FDB entries.
On Thu, Jul 21, 2022 at 1:45 PM Vladimir Oltean olteanv@gmail.com wrote:
Why is it "not really so nice" to "trigger MAB" (in fact only to learn a locked entry on a locked port) when initiating the 802.1X session?
The consideration is mostly to limit (not eliminate) double actrivation, e.g. activation of 802.1X and MAB at roughly the same time, so that the daemons will have more to do coordinating which has the session.
You can disable link-local learning via the bridge option if you're
The issue here is that you can only disable it bridge wide and not per port.
really bothered by that. When you have MAB enabled on an 802.1X port, I think it's reasonable to expect that there will be some locked entries which user space won't ever unlock via MAB. If those entries happen to be created as a side effect of the normal EAPOL authentication process, I don't exactly see where is the functional problem. This shouldn't block EAPOL from proceeding any further, because this protocol uses link-local packets which are classified as control traffic, and that isn't subject to FDB lookups but rather always trapped to CPU, so locked or not, it should still be received.
I'm only pointing out the obvious here, we need an opt in for MAB, and the implemented behavior I've seen here kind of points to mapping this to "+learning +locked", where the learning process creates locked FDB entries.
If we need an opt in for MAB, you are right. Only then I think that we need to solve the link-local learning issue so that it is disabled per port?
On Thu, Jul 21, 2022 at 1:45 PM Vladimir Oltean olteanv@gmail.com wrote:
On Sun, Jul 17, 2022 at 09:20:57PM +0200, Hans S wrote:
I'm only pointing out the obvious here, we need an opt in for MAB, and the implemented behavior I've seen here kind of points to mapping this to "+learning +locked", where the learning process creates locked FDB entries.
I can go with the reasoning for the opt in for MAB, but disabling link local learning system wide I don't think is a good idea, unless someone can ensure me that it does not impact something else. In general locked ports should never learn from link local, which is a problem if they do, which suggests to me that this patch should eventually be accepted as the best solution.
On Sun, Jul 24, 2022 at 10:09 AM Hans S schultz.hans@gmail.com wrote:
On Thu, Jul 21, 2022 at 1:45 PM Vladimir Oltean olteanv@gmail.com wrote:
On Sun, Jul 17, 2022 at 09:20:57PM +0200, Hans S wrote:
I'm only pointing out the obvious here, we need an opt in for MAB, and the implemented behavior I've seen here kind of points to mapping this to "+learning +locked", where the learning process creates locked FDB entries.
I can go with the reasoning for the opt in for MAB, but disabling link local learning system wide I don't think is a good idea, unless someone can ensure me that it does not impact something else. In general locked ports should never learn from link local, which is a problem if they do, which suggests to me that this patch should eventually be accepted as the best solution.
Hi Vladimir, sorry, I forget myself. We cannot use +learning as an opt in for MAB with this driver, as there will be no HW refresh and other interrupts like the age out violation will not occur either, which will be needed further on. If we really need an opt in for MAB, I think it will have to be a new flag. Hans
linux-kselftest-mirror@lists.linaro.org
-
Hans S -
Ido Schimmel -
Vladimir Oltean