*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;
If 802.11r is enabled (security.ft=yes) some devices can’t reconnect to an AP after the latter gets rebooted. In my case it was an iPhone with iOS 15.5. Logs show the following:
VxLAN makes more sense in a datacenter environment where you want to interface with virtual machines. MPLS and VPLS and SR-MPLS make more sense in the service provider space.
To me the big advantage of MPLS and VPLS is the decoupling of the MTU setting from IP, so that you don’t end up with devices creating IP frames larger than 1500 bytes for things like management traffic, but are still able to provide for layer 2 tunnels to transport 1500 byte packets or larger (in case customers want to run Q-in-Q over the circuit).
*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;
If 802.11r is enabled (security.ft=yes) some devices can’t reconnect to an AP after the latter gets rebooted. In my case it was an iPhone with iOS 15.5. Logs show the following:
mac-address@wifi2 rejected, can’t find PMKSA
This looks like the PMKSA generated as last step of EAPOL (which in 802.11r is kept by the client to be reused for future (re)associations with the same AP, skipping time consuming 802.1X EAP) gets lost on AP reboot. If the client tries to reconnect with the cached PMKSA, it is not known to the AP anymore and it “can’t find PMKSA”.
Yes that is of course what is happening. What is not so clear is why that would result in “some devices can’t reconnect to an AP”.
I would think the AP would send an appropriate errormessage and the clients would then go through the complete authentication cycle instead of using the fast PMKSA.
It looks like this does not work correctly in this version…
I would think the AP would send an appropriate errormessage and the clients would then go through the complete authentication cycle instead of using the fast PMKSA.
Yes, obviously that is what’s going wrong.
According to 802.11r, it is not based on error codes, but by the AP initating a full IEEE 802.1X handshake if the PMKID in the STAs (re)association request is not known:
“If a non-AP STA in an ESS has determined it has a valid PMKSA with an AP to which it is about to
(re)associate, it includes the PMKID for the PMKSA in the RSN information element in the
(Re)Association Request. Upon receipt of a (Re)Association Request with one or more PMKIDs, an AP
checks whether its Authenticator has retained a PMK for the PMKIDs and whether the PMK is still valid.
If so, it asserts possession of that PMK by beginning the 4-Way Handshake after association has
completed; otherwise it begins a full IEEE 802.1X/EAP authentication after association has completed”
Seems like a bug were the AP fails to do so, at least for iOS 15.5 STAs.
But this information should be enough for MikroTik to reproduce the issue.
The is a very good reason to strongly advise the operator to secure the device properly. It isn’t a good reason to require the operator to physically travel hours to a site after they have already secured it. Ensuring that the means to secure a device properly is the responsibility of the vendor. Locking the operator out of the proper operation of the device because the vendor supposedly knows better is another matter entirely.
There’s the problem right there. This device is being controlled from a network-controlled power distribution device (PoE off of the management switch) and hard power cycling the device doesn’t change the device mode like it should.
Others have reported it as well. It looks like a bug that should be fixed.
Definitely. In the meantime, I’ll continue looking for a workaround for the “feature” above.
This feature is not intended to protect the operator that knows how to secure a device properly. It is intended to protect the “unpack, plug-in, use” type of operator that uses the device in a home network.
Also, there is a long history of security vulnerabilities in RouterOS (and of course in almost every kind of software) that has affected MikroTik routers whose operators thought they had sufficiently protected their device (although that usually wasn’t really the case; they may have set a strong password but they e.g. allowed admin access from the internet).
The result has been that MikroTik routers are in large botnets where they are used to DDoS other users and be a stepping stone to attack networks behind those routers.
The device-mode feature was added to protect routers that have been hacked from becoming part of a botnet.
(of course in the current state it does not accomplish that, it requires more releases where e.g. the default mode setting is more restricted than it is now)
The thing is, with RouterOS, even the most knowledgeable sysadmin is not in full control of the container host. If there’s any possibility that a rando could get a rogue container onto your router, the possibilities for mischief are immense.
Notice that most of the mitigation options aren’t in the sysadmin’s hands. In some cases, we can see that MikroTik cannot have addressed all of these paths, as with the inter-container communication item: sometimes, the router’s admin may want that.
Until RouterOS + WinBox become as complex as Docker Desktop, exposing every last twiddly configuration item, I don’t think it’s reasonable to expect that RouterOS containers are fully secure by default.
And if we ever do achieve that extreme level of configurability, it will ipso facto allow people to misconfigure it.
I for one am glad containers aren’t enabled by default, and that it requires hands-on access to enable them.