Gateway protection in an DNA Center SD-A environment

[HansK_NL]

Hi everyone,

I need your help and insights on the subject of (specifically) protecting the MAC address of the subnet gateway from being spoofed by an endpoint.

We recently received a report pointing out the lack of protection of the gateway MAC address in our environment. The pen/hack tester spoofed the MAC address of the gateway of the subnet he was put in through ISE policies and demonstrated that it was possible to intercept traffic from other clients in the subnet (and where the traffic was encrypted, the captured traffic could be decrypted offline, etc. etc) His recommendation was to implement Dynamic ARP Inspection.

Now, Dynamic ARP Inspection is very powerful, but is cumbersome in environments where static IP addresses are present on endpoints.

DNA/Catalyst Center does not seem to implement any form of gateway protection that I know of. And, in an SD-A environment the hacker will only impact the switch he is actually connected with, all other switches are not impacted (nature of SD-A), so the scope of the issue is limited, but the threat is real.

What alternatives can be deployed in a network of Cat9000 switches, SD-A managed by DNA Center and ISE?
So far, this is what I can think of:

• Both "Anomalous Behaviour Detection" and "Anomalous Behaviour Enforcement" from ISE (not yet enabled due to the migration we're in)
• SVIs in an SD-A environment are programmed with a software defined MAC address. Collect all of these MAC addresses into an endpoint group and add these to a blacklist policy in ISE
• Implement DAI and deal with the hassle.

Are there other alternatives out there?
Are there notable pro's and cons's regarding the first two options that would impact decision making?

Again, any help and insight is welcome.

Cheers, Hans

[Torbjørn]

The best option in my view is to implement DAI for all VLANs where you are able to use DHCP through templates. For VLANs/VNs where DHCP isn't an option you will probably have to rely on ISE profiling as I don't think adding static ARP table entries for static hosts is achievable unless you configure it manually per edge.

[HansK_NL]

Hi Torbjørn,

Can you eloborate on how ISE Profiling is going to help circumvent the static IP addressing issue with DAI?
I don't see a connection between the two of them...

Cheers,
Hans

[jedolphi]

Fabric Edge Nodes natively protect against IP and MAC theft for both Anycast Gateway (SVI) and endpoints, unless those protections have been switched off. Did PEN tester connect through wired or wireless? Did PEN tester connect to Fabric Edge Node switch port? What IOS XE version on Fabric Edge Node? I'll cover it at Cisco Live Melbourne next week. Recordings should be up in a few weeks on ciscolive.com. Session code BRKENS-3555. Thanks, Jerome

[HansK_NL]

Hi Jerome,

I appreciate you answering.

The PEN tester was connected to a Fabric Edge and on a regular client port.

We're running an SD-A that was first build in 2020 (release DNAC v1.3) We noticed that a lot has changed in DNAC and not all design changes were carried through (thinking about ISIS L1 and L2 updates)

Which protection mechanisms are you thinking about, because this is exactly what I'm looking for.

Cheers,
Hans

[HansK_NL]

Oh, IOS-XE 17.6.5 + selected SMU and 17.9.5 + selected SMU

[jedolphi · Accepted solution]

OK. IP and MAC theft warnings went into the IOS XE in 16.x (can't remeber exact version), this would Syslog a theft message but not block the theft. IP and MAC theft protection went into IOS XE at 17.9. IP and MAC theft protection are native to SDA Fabric Edge Nodes as of 17.9. It uses Device Tracking, DHCP Snooping, RA Guard and DHCP Guard. I'll explain this in BRKENS-3555 at Cisco Live Melbourne next week. Slides should be available on ciscolive.com in 2-ish weeks. Happy to try and answer specific quesitons here in the iterrum. If it's not working in your network for some reason you could raise a TAC case or ask here. If it's urgent TAC case is best.

[Torbjørn]

I must be missing something here. I thought/think IPDT "only" populates the local binding table, does this also enable DAI? DHCP snooping, RA guard and DHCP guard won't protect against what @HansK_NL describes here.

[jedolphi]

Hi, DT protects against MAC and IP theft on Fabric Edge Nodes in SDA. It consults LISP CP to determine if the IP/MAC is previosuly registered, then polls the previously registered location, and then allows or blocks a new IP/MAC based on probe results. BRKENS-3555 will unpack the details.

[Torbjørn]

Cool! Wasn't aware of that.
For clarification: does DT only block registering to the EID table, or into the local CAM as well?

[jedolphi]

Yes, IP/MAC theif is fully blocked, no comms permitted on the Fabric Edge Node or over LISP/VXLAN.

[HansK_NL]

Aha than we have found our culprit, root cause and solution. We have a working DT solution with all features enabled (as is default in SD-A) But we're running IOS-XE 1.7.6.5 on the switches involved in the P&H testing, so theft is detected, but not blocked. We're already rolling out IOS-XE 17.9.5, which by default will both detect and block. And if this works as planned, we do not need to think about Dynamic ARP Inspection (DAI)

I'll check for publication of BRKENS-3555 and study its contents with interest.

[jedolphi]

DAI not required or compatible with SDA. Yes, please test 17.9+ and raise TAC case if something not working.