Feature Request: Port-Security & Dynamic Arp Inspection

@MT

Last week we are in the middle of presentation for a potential big customers and we stumble a requirement that caught us off guard, the potential customer want to migrate their ageing cisco catalyst gear to Mikrotik they are almost sold to the extent the purchase order is about to sign but the last question of their CTO hang us dry and put everything on hold, the CTO asking for port-security & DAI equivalent of cisco, we told them the close possible we can get is 802.1x and the guy simply said hold on something isn’t right

As a MT consultant i was really ashamed and thought yeah how can we sell this thing if basic feature like this virtually non existent on the product offering

Any thoughts?

Sounds like really nice features to have specially on the switch-series.

Port-security with both dynamic (that resets when disconnecting interface) aswell as sticky (to be included in the config and survive a reboot) along with DAI (Dynamic ARP Inspection) and IP Source Guard are really nice features to have on the access-layer.

Same with DHCP-relay and DHCP-snooping to force the DHCP requests to your choice of DHCP servers while including Option82 information of where the DHCP request originated in your network (switch + interface) and when reply gets back the assigned IP will be used by IP Source Guard to dynamically build an ACL to drop any other source IP’s on that interface.

While at it since Mikrotik is different it would be nice with an ACL style per interface similar to how Cisco, Arista and the others works - would make life so much easier when converting equipment from Cisco/Arista/Juniper etc into Mikrotik.

Indeed, this feature is not optional and MT should implement this feature soon most major brand support these

Dynamic ARP Inspection and IP Source Guard are my most missed L2 security features when it comes to Mikrotik.

Yeah, we lost the sales already and I can even look in the eyes of the customer, their CTO are willing to wait if only Mikrotik can/will commit a timeline but that’s all a dream now they don’t even reply to my support ticket with regards to this issue, sad it’s hard to push them in the right direction they don’t really know their customer because if they do they are going to prioritize the needs of “ISP” just llike us we need a solid routing and switching platform not a router with a container/media server/rose storage which we can moved on without.

I’m not saying other features beyond routing and switching is not important but the order of priority which features are going to hit in the street doesn’t add up

Not a proper solution, but talking about Port Security, you can stick a port to only one mac (the first one seen by this port) if SwOS is used. I don’t know why, but this option is not available on RouterOS, even on the last versions.

Inside Switch Chip ACL (now talking about RouterOS) you can also create rules to allow a single mac (or vendors for example, using the first 6 numbers from MAC with mask), but this is a manual setting… not very useful.

As I mentioned before, not a “solution” but some workaround to save this sale.

In as much as we want it too it’s dead on the water already, DAI was closely tied up in DHCP snooping database and the customer will surely not going to do any manual task on this even though it’s possible in Cisco and also as an Integrator you want a proper solution in the long run

I’m just barely scratching the surface here how about the other enterprise features that most people here waiting for years sigh… very frustrating

+1 for that… I have a project where I have 4 switches connected with fiber to core switch and 5009.

Every access port needs to be protected and my workaround was by using 802.1x and MAC auth. So it was quite a hassle to add all devices to UM. It would be nice to have normal solution and not some workaround. Also not to mention that i have 45 devices and L5 license allows only 50 active sessions.

I think port security is already there but just doesn’t have sticky option [bind on first mac that connects to port]
in /interface bridge port set [find interface=etherX bridge=bridgeX] learn=no
and /interface bridge host add bridge=bridgeX interface=etherX mac-address=AA:BB:CC:FF:11:22

about DAI +1

but currently I’m using 2 similar alternatives (that are not perfect but useful)
requirement : every device in the network should be directly connected to mikrotik device (have individual port)
one alternative is
enabling dhcp-snooping on bridge
disabling broadcast-flood on every port of switch
if there is a uplink Router that acts as (DHCP-Server and …) I set uplink port trusted and also enable broadcast-flood on that port
now there will be no arp and dhcp communication (because of disabling broadcast flood) except on switch and router uplink(if there is one) so I enable local-proxy-arp on one (switch or router ,usually uplink router) so every device in the network will communicate with mikrotik that has local-proxy-arp=enabled

another alternative that had better result is the same as above except i isolate every port usually with switch chip features or if there is a good cpu using horizon in bridge ports

Also securing DHCP with static-only pool and also add dhcp-lease to arp will help

So this is why many organizations have been hacked, they do not have port security sticky and dynamic arp inspection…
If the answer is no, Why is this so important…
Not IT trained so all I hear is geek speak and of course, I have to ask the basic question…

the reason that companies don’t get hacked by this way is MITM attack should be an inside job or some stranger somehow can connect to network, or a device or some devices get infected by some sort of hack malware. in real life chances are low but sadly in this days IT admins always should be prepared for anything
in worst case scenario if there is encryption in application layer (tls / ssl ) attacker can just interrupt traffic and make some disconnection or causing tls errors but if there is no encryption in application layer, attacker can sniff traffic for data and passwords (as in this days every application uses some sort of encryption, data and password sniffing is unlikely)
although if you limit macs per interface , isolate the ports and limit arp to solid arp-table and limit dhcp to known mac-addresses , there shouldn’t be much concern.
but usually companies have standards that IT manager should provide , and this standards are usually concrete instructions.
in most cases companies don’t care which instructions is critical and which is not , but IT admin or IT manager should simply provide it for them

a sniffed and then spoofed MAC addr. later, and all your sticky port security quite goes down the drain.
and yes, i tested this in real-world conditions many times and i always got the same question… “but how to secure the port then?”
… dot1x