How widely is 802.1x for Wired Ethernet deployed in the industry?

[Ricky Sandhu]

Hey everyone,  now that ACS is End-of-Sale and soon to be End-of-Support, we are one of the organizations that stuck to our trusty ACS deployment until the very end.  Now that we are being forced, we have finally decided to make the move to ISE.  I have been working on this for last couple of months and finally have a working, in-production, ISE deployment.  When I say "in-production", I have RADIUS configured and setup to authenticate Remote Access users for all our Anyconnect termination points (ASAs), some Wireless 802.1x has also been moved over and TACACS+ soon to be migrated over to ISE.  One thing we have never played with is 802.1x for wired ethernet networks.  We have a large number of branch offices spread throughout North America and a lot of these branches do not have an IT staff present onsite.  Because of this, a lot of users, culturally, aren't very aware OR simply don't care about IT security.  We regularly have users bringing in small desktop switches and sharing their network connections with personal devices.  REALLY hoping to put an end to this with ISE.  Now,  back to my original question.  How widely is 802.1X for Wired networks deployed in other organizations?  I don't want to be Town Crier touting the roll out of 802.1X for ethernet only to find out down the road that it's got more issues than it solves.  I understand the in's and out's of 802.1x when it comes to Wireless, I just have never deployed it on physical switch ports.

[Surendra]

Simply put, it is very widely used for physical ports on switches. To know more about the wired deployment, please refer : https://community.cisco.com/t5/security-documents/ise-secure-wired-access-prescriptive-deployment-guide/ta-p/3641515

[Damien Miller · Accepted solution]

So my two cents on this is that dot1x is by no means perfect, but it helps enterprises reach certain security and visibility goals within their environment. It's about finding the balance between letting everyone and everything on the network, and creating a management nightmare. Some enterprise's are mandated by business partners to take on wired authentication while some choose to do it to on their own accord to improve security. You appear to have already hit on some of the reasons why your company might want to take on a wired ISE deployment.

I've helped clients with simple thousand user wireless only ISE deployments up to complete wired/wireless dot1x + trustsec for fortune 500's. One thing is for certain, the volume and scope of dot1x projects continues to increase. I know I'm not alone in this either, the Cisco Live sessions pertaining to ISE over the past 6 years continue to increase in attendee count. While no one quotes numbers publicly, the growth of ISE within Cisco's product portfolio has been extremely good.

My recommendation is to pilot it since you already have the ISE infrastructure. It wouldn't require a large investment to test wired dot1x in a limited fashion, a site or two. Take a stab at monitor mode, get the visibility piece, work towards enforcement mode if it seems feasible. I can say from past projects that there is significant difference in the time+effort to go past monitor mode. I also can't stress enough testing and standardizing code versions on switches, having engineers blindly applying dot1x configs to various revisions of IOS opens up a world of hurt I wish on no one.

[Ricky Sandhu]

Thanks Damien. I was also thinking of piloting first. We do have a bunch of old cisco switches in some offices that I want to upgrade first. You also brought up a good point about IOS versions on switches. Been burned by this way too many times. Regardless, security is obviously paramount and we have now seen enough incidents to finally have the backing of business to move forward with this and that's why I was looking into it.

[Arne Bier]

Great topic of discussion @Ricky Sandhu  .  I work mainly in wireless space and I am surprised at how many customers I come across who still hang onto their PSK WLANs because the thought of 802.1X fills them with dread.  Most networking kit can handle the tech, but the organisations/people are not ready for it.  Therefore I think there is still a lot of good work to be done out in the field to educate customers about wireless and wired 802.1X - I believe the wired variant is a bit special compared to wireless and this is the one that trips up most folks.

  @Damien Miller it would be nice to have a separate thread to hear your perspectives on getting customers ready for the TrustSec journey.  How do you approach it, and how do you plan for it. 

In my world that is still the ultimate unknown for many customers and I don't claim to fully understand it myself - but I am slowly getting there. In fact I think I had a Eureka moment today after watching a bunch of Labminutes videos on trustSec from way back.  I find his stuff so well done and more digestable than any book or white paper.  Or at least, I find it's a fantastic ice breaker for this scary topic.  I think TrustSec has great potential but in my experience as soon as someone mentions the T-word, the room goes uncomfortably silent.  People need to "see to believe" :)

[Sheraz.Salim]

Good Topic. I have to appropriate and put my input though. It much easier to implement 802.1X on wireless compare to wired. as you have to push the config on each single switch which is a time consuming and as said ealier in above post with different IOS version/s. in contract to wireless it more easire as all the setting are in one place in the controller.

in regards to Trust-Sec yes its scary in a way. Engineer do not have the exposure of this technology yet. we are still living in old school ACLs and most of us a happy and not ready to adopt the new technology as we have to go to read and lab again. just to your attention of cisco DNA where a trustsec rule can be deploy with a single click of touch. 

would be great to hear how you guy are implementing in what phase of tsec. technology is keep reinvent very fast. having said in this domain we have to still on top of skill of encounter these technologies. 

[Arne Bier]

Yes there is a danger of getting "left behind" while the world is moving on with Cisco SDA/DNA-C etc.  When you have to explain what LISP and VXLAN is to customers, you can see the momentary blink in their eyes as they try to regain their composure.  "Ah yeah, sure, right, yes I see ... ermm"

I am also trying to get my head around Cisco DNA-C and Cisco SDA and it's pretty on Powerpoint.  I think if one manages to deploy it and all works well, then it's a win for the customer.  But when stuff breaks, who is left to debug this stuff?  It will be a handful of wizards somewhere, while the rest of us contemplate "reboot/rebuilt/reset" strategies.  LOL.  Ok. Maybe not - but it would be some knee jerk reaction UNLESS you knew what was going on under the hood. 

Speaking of under the hood - people make the analogy of cars and the complexity in modern cars - no average person knows how to fix a car anymore.  If something breaks then we see a mechanic - most of the time they don't know either - and they just rip and replace until it works.

[Ricky Sandhu]

Thanks Arne.  I agree with all your points on TrustSec. "There's a storm coming!!" (What movie?)

I was recently in a Cisco course and when we came across the topic of TrustSec, the instructor paused for a second, turned away from the whiteboard, and said, "Folks, if you REALLY want to make good money in future, TrustSec is the way to go.  Master TrustSec today and you will be ahead of the majority."

I think TrustSec is an excellent technology, if implemented correctly. All the small pieces have to work perfectly in unison.  This could get a major nightmare for larger deployments. A tiny mis-configuration somewhere could cause massive headaches elsewhere.  Phased approach in this case would be your saviour. 

[Damien Miller]

In theory, DNAC could potentially simplify the TrustSec roll out from a config standpoint, but the thought of troubleshooting advanced problems in topics not many traditional networking people have worries me. SDA puts me off because it aims to simplifying networking with those advance technologies. The config for just TrustSec (no SDA) is not complicated. Over simplifying a bit, but a few global commands change, configuring uplinks and WAN to carry tags, all easily rinse and repeat.

I really like TrustSec, but it has some large technical and operations challenges. It really is a discussion of it's own.

1. You really need supported hardware to take full advantage, sgacl's and inline tagging are the heart and soul of the solution.
2. If you want east-west enforcement then you also need a scalable way of carrying sgt's across the WAN. SXP can work in small environments but it's an inscalable resource hog when used across the WAN. You're then left with iwan/dmvpn to carry the tags inline, iwan is the walking dead, and inline sgt support is not available yet in the viptela/cisco sdwan.
3. Finger pointing. Pre TrustSec, everyone blamed the firewall guys when traffic flows failed. Post TrustSec, everyone just blames TrustSec. It's silent and deadly when you start assigning different tags to various business units, users, endpoints, and servers. It honestly requires a dedicated team, treating it like firewalls in the large enterprises. Most companies don't have dedicated ISE resources and have trouble hiring people, even fewer of the people in the market can troubleshoot TrustSec. The talent usually has to be homegrown.
4. The unknown traffic conundrum. You can write policy for tagged to tagged traffic, but it gets complicated when you introduce untagged traffic that's present in every environment. Some examples of this are sites yet to be implemented, B2B tunnels, or internet traffic. You can either block of allow untagged traffic, you have to account for and work around this.

It's time intensive to build and manage solutions.

[Sheraz.Salim]

Thanks for unleashing the hidden truths of trustsec.

[jmcgrady1]

Ive only worked with ISE for 802.1x for a short time. Its such a heavy, fickle, ponderous beast! At its back end, its a full Oracle database server. Ive worked with up to version 2.4. Are the later versions lighter and more robust?

[Marvin Rhoads · Accepted solution]

@jmcgrady1 

Nothing about ISE is light. That's been the case with every release from 1.0 though the current 2.6.

Robust? Well defects are fewer than they used to be so that's a good thing.

Like most software, new releases come with warnings and caveats. Cisco typically doesn't recommend going into production with a release that's not "gold star" status unless you are forewarned and accept the risk of service-affecting bugs. Usually one only does that because a new feature addresses a critical business requirement and the deployment plan is to test thoroughly before go-live.