A previous blog discussed shortages of networking and especially security staff, along with some parts of the changing landscape.
Other recent blogs considered shifts in Security from firewall / positional security to endpoint-based or even application-based.
TL;DR: This blog attempts to describe what a future network might look like. Of course, that will be a moving target.
The prior blogs looked at all sorts of technical possibilities but not what the big picture might look like.
This also partly answers a question a reader asked, namely what impact changes (cloud, etc.) might have on staff, especially senior networking or security staff. I’ve got a follow-on draft of a separate (and long!) draft blog specifically on that topic and have revised this blog with that in mind. Apologies for the length, every time I try to shorten my blogs, especially these two, they seem to get longer as more things occur to me!
I’m going to provide some brief lists of factors that are driving change. But rather than going in-depth on them, the main focus of this blog is to present an extreme case study as something concrete to think about. And maybe it isn’t all that extreme after all! After all, someone built this several years ago, and I’m just imagining scaling that up.
What Changes?
I’ve been helping a customer develop a short list of current or potential 1, 3, and 5-year projects for discussion with their senior management. What needs fixing or improvement is one set of inputs. Strategic plans, simplification for agility, etc., and predicting how various external and network product shifts will affect the business/tech teams.
Here are some of the driving factors (in bullet form, since I’ve discussed them before):
- ZTA (Zero Trust Architecture).
- Increasing levels of ZTA will likely mean network, security, and app changes. I happen to like the potential of DNAC plus ISE for security. Fully leveraging that may require sharing equipment rather than “my toys, your toys” (so to speak).
- Trying to provide security when it is not “baked in” is not working out well. Impact = organizational changes, at the very least. Need for more staff?
- Tighter coordination or merging of the network and security teams? And server/app teams? Cross-functional teams or differently structured teams?
- Cloud, and the effects of moving some but not all apps to various clouds
- Climate change. Fewer people in cars is good. Fewer people on mass transit might be somewhat good (less crowded at rush hour), but not enough people on mass transit might create financial viability issues, as has happened with COVID-19.
- In 20 years, will young people wonder, “what is rush hour”?
- SD-WAN (more, or evolution of SD-WAN, or SD-WAN with more segmentation?)
- Continued full or partial WFH. How does that change security? Does it cause remote access VPN to replace site-to-site VPN? That is, offices are just like WFH except for in-person meetings, casual contacts/conversations, etc.?
- Increased VDI for security control over remote workers? (BYOD accessing VDI corporate desktop enables lockdown and audit trail?)
- WLAN shifting from optional to primary connection as part of hoteling, personal device access as the main workstation, etc.
- Automation of campus switch and/or data center switching/infrastructure means new skillsets, new troubleshooting approaches, etc.
- OT/IOT
- Increased levels of monitoring and threat response?
Skills and Changes
Some non-technical factors are likely to matter, especially to management. Included among them:
- All areas (networking, security, server/apps) need cloud + non-cloud skills: broader skills.
- Products such as Cisco’s ISE, DNA Center, and ACI or DCNM require new skills. It takes time to develop solid skills in any of those (1 year each or more?) If you figure a modest networking shop ends up with one person solid in each of 3 of the above tools, does that mean smaller shops have a barrier to adopting such products? Unless we see targeted outsourcing such as ISE management as a Service.
- New skills driving automation products (DNAC, ACI, or fancier automation tools). They may be needed up front in design and planning and some in support of deployment or higher-level troubleshooting.
- I suspect only rather large organizations can afford thorough DIY automation. Smaller sites might have DIY tools for pull/push of info and carefully targeted automation. And buy products for bigger automation solutions.
- Outsourced/part-time staffing? E.g., as a way to have affordable access to advanced skills without paying to have such person(s) on staff. [As I’ve noted before: NetCraftsmen currently provides such services, and has been doing so for several years now.]
- Network as a Service (NaaS) to offload some staffing costs. Note the deploy and ongoing break/fix work is perhaps easier to outsource? To some extent, tool skills (DNAC, ACI, Infoblox, or other vendor counterparts, etc.) may keep day-to-day tasks in-house and outsource more advanced or how-do-I-do-this JIT training.
- Security may become more risk/audit/compliance/monitoring and less technical? (The ZTA and related FISMA documents make it clear that a lot of governance/management/tracking is needed.) Or Security may split into a governance team, an operations team, and an implementation team?
- Companies could subcontract out security incident response for tool-detected incidents or complex situations. Staff on retainer, in other words?
A Future Network
Let’s now take a look at what a radically restructured (or new) network might look like. Part of this goes to the question: How Do I Achieve Simplicity? This is intended as a thought exercise or a stimulus to thought, not a recommended design, because your requirements may differ.
One answer is zen-like: do away with what you don’t really need. I’m tempted to cite Marie Kondo here about getting rid of objects that do not “spark joy.” However, I’m concerned that some of us might feel that few networking objects might be thought of as sparking joy. So, let’s leave Marie and joy out of this discussion!
Parts of this resembles a company, “Company X,” that I did consulting work with a few years ago. Small and a growing startup, but that’s where concerns like staffing and simplicity can provide major benefits.
Their network was a lot different than I had expected or had seen before. They had perhaps 100-150 staff working in a large, mostly open space (and from home or dorm rooms). The staff was mostly developers and data analysis/report production for paying customers. They’d likely started out with strong server/app skills and no network staff, building a low-cost, low-maintenance network. It worked for them and remained very light on support staff, leaning towards server admin with some networking skills.
It was by no means perfect. There were WLAN problems due to loft-type space with very high ceilings plus hanging lights and HVAC ducting. Putting APs on the high ceiling was NOT the right answer! Wire tying them onto steel support beams, ditto. Omni-directional antennas and no internal barriers, etc. I made some suggestions, and that eventually got sorted out.
The starting point for the Company X network description is that the wired and WLAN network was there for pure Internet connectivity over WLAN. Minimal wired network. Jam bodies with laptops at trestle tables as needed, etc.
Note that college dorms are evolving in this direction: WLAN-only for students because it can be provided at a lower cost than multiple wired ports in every room suite. Plus, maybe 70% of students live outside dorms anyway. Colleges and printers: likely either bring your own and connect wirelessly to it, or shared central printers with cost chargeback.
So, workers of the future may not expect much more than basic connectivity.
Connecting to anything “internal” at Company X required remote access VPN to a server in a colocation (CoLo) space. This worked the same at home as in the office. For the college students on staff, this provided a uniform environment for them. This also saved the company from having to do 802.1x/NAC.
This brings up thoughts on whether “Untrusted LAN” fits ZTA? The remote access VPN handled authenticated access to the servers. The BYOD side was not really secured. But all the work was being done remotely on servers.
I’m not sure how printers were handled—perhaps driven off a print server in the CoLo, perhaps by split tunneling.
The Internet router at the site probably had ACLs limiting traffic to just VPN and perhaps print server to printer traffic.
Off-the-wall thought/product idea: how about a simple Ethernet “bump in the wire” small device that you could plug a printer etc., into, and then plug it into the wall. One that is centrally controlled (no remote setup, setup via DHCP perhaps) and does VPN for a device that can’t do VPN.
No desk phones. Everyone just used their cell phones, even management (as far as I know). Softphones like WebEx teams, jabber, etc., would have worked. Similarly, for software-based meeting apps.
I’m deliberately being a bit extreme here, but then again, I’ve personally never had much use for a separate business phone. I’ll also note a couple of my offspring have two cell phones, one for office use, to control phone access to apps and provide data security / remote wipe. (Gov jobs and/or lawyers.)
That’s another answer, and probably a good one when staff are not tied to desks, e.g., WFH or remotely some or most of the time. (I’ve added this as a topic for another blog!)
The data center wasn’t. That is, it was just racks of equipment in a CoLo. These days, we might instead use the cloud. And perhaps even get some as managed services. A security debatable lurks there – how much can you rely on cloud or SaaS providers to secure virtual devices and virtual networks. You’re who gets sued. But that’s also a topic for another blog.
Basically, what I’ve just described might align with a hoteling sort of environment. That’s fine if you don’t have meeting-related devices etc., requiring wired connections. But if they are tied to meeting rooms, there still might be a very limited need for wired ports.
For highly mobile WFH and elsewhere staff, the above makes a lot of sense to me. Your organization’s requirements are what makes it a good or not-so-good fit.
Diagram
I like my blogs to have at least one diagram, so I’ve put one below. It purports to show the bottom floor with wired computers, hence more switches. The top two floors only have wireless laptops/users, so they need fewer switches. And yes, the APs need wired uplinks, printers may also need them, and some OT/IOT devices may need them. I needed to tell you that because I couldn’t quickly come up with a diagram where that was obvious.
And yes, the closet or in-wall switches still would have dual uplinks to distribution/core /spine switches. I only suggested those with brown lines to avoid clutter. Or having to spend a lot of time positioning lines to look uncluttered.)
The main takeaway here is: going mostly wireless probably results in having fewer switches. Closet stacks might be reduced to one or two switches versus four or more.
Possible exception: OT/IOT sensors etc.?
For what it’s worth, I checked, the documentation claims the Catalyst 9300 can do NAT. I haven’t tried it.
Furthermore, perhaps in the near future, the (edge) switches might become able to do centrally automated IPsec VPN over the Internet connections. That could be handy if you don’t need full SD-WAN capabilities, especially if automated/simplified. If that happens, that would be another design alternative. Check Cisco’s Feb. 3, 2022, Cat9K announcements in this regard: new models support IPsec for “lean branch”!
Re printers: they’re a detail, TBD. Various solutions are possible.
OT/IOT devices might be wireless (more set up as a drawback?). They and centrally controlled printers might need a separate wired VLAN that does feed into SD-WAN. Or maybe they are Internet-controlled (Meraki?). So yes, some details are being left open here. I can imagine Meraki-like registration based on cell phone scanning of a Q code on a printer or IOT/OT device. Or a bump in the wire device.
The point is this is a thought exercise, not an actual completed design. And if you’re going to get real about a minimal design, it’s this sort of corner case that is going to need to be addressed. So, my diagram is imperfect and lacks some answers, but hey, that’s the real world.
Exceptions
The wild card on the wired side might be OT/IOT devices. Cisco has small in-wall switches providing copper to optical connections for such. They could also be useful in a “mostly wireless” environment and/or new office buildout.
Exceptions:
- Stores, small offices, staff not used to work in a mobile manner. Or staff using dedicated cash registers or workstations, not provided with a laptop. (But I’m seeing increasing use of cell phone-based apps, e.g., for things like checking out a rental car? Or Square for checkout.)
- Executive suites need for large monitors/standalone meeting terminals.
- Conference/Meeting rooms: See above.
- Warehouse OT/IOT devices require highly reliable or just wired access. Don’t casually dismiss this category, as security cams, networked thermostats, etc., are OT/IOT devices. I expect them to become mostly wireless, too: MUCH easier to install than pulling cable! Maybe harder to troubleshoot. Centralized diagnostics will help with that.
- Call center staff, wired phones for voice quality? (Although getting staff a good Internet connection and having them WFH may grow in popularity?)
- Wired connections for less-technical staff.
That last one is perhaps a big item. How does support staffing change if user WLAN access has to be supported? Is that generational? My kids seem to have no problem with glomming onto wireless and working from anywhere. Did college teach them that?
Ok, so at this point, we have:
- Campus/WFH user using WLAN and remote access VPN
- Perhaps some small office LAN use, e.g., printers, dedicated segments, etc.
- No data center: CoLo or cloud.
If you have substantial campus presences, then maybe something like Cisco DNAC fits well to manage the large and small switches and APs, and with perhaps lower skillset, shifting from CLI and tech to more GUI-centric skills?
If you have data centers or significant CoLo/cloud, then something like DCNM or ACI might still be present and in use. Heavier use of SaaS perhaps reduces the footprint?
The remaining component is WAN. For that, my recent thinking is that good design is to get your major offices or corporate hubs well-connected to something with robust connectivity, i.e., either a CoLo or cloud. CoLo space may be advantageous as being cloud-agnostic.
“Why?” you ask. The answer is NaaS. Once you’re in a CoLo, you can rapidly order up connectivity with various degrees of managed services. E.g., to different cloud providers.
If your organization is international or widespread in several cloud regions, then you might also use NaaS, possibly from your CoLo or cloud providers, to leverage their long-haul connections for inter-regional connectivity. Based on what I’m hearing, that could be much cheaper than getting your own long-distance circuits (economies of scale, but YMMV).
But Security!
ZTA (Zero Trust Architecture) is the new and likely mandatory approach. I’ve just skimmed it so far and don’t claim expertise, just some knowledge and awareness. A couple of aspects caught my eye.
You can argue that the above gets away from firewall/barrier style security and does run across untrusted networks. That could be a plus! (Another reason for this blog.) Or you can try retro-fitting your firewall-heavy network to layer in ZTA, which I can make a case for. But it is probably more complex and less agile. So you’d need to make sure it is providing offsetting value.
Part of ZTA is context-awareness. This immediately makes me think of Cisco ISE or Aruba ClearPass, as the big current players in that space (that I’m aware of). Does context and posture awareness derive from the remote access connection instead?
With endpoint agents to protect the phone or laptop and with remote access, you have two good points for enforcement: the end device plus the VPN termination point. They also seem likely to be suitable for applying context-sensitive rules.
ZTA does have the concept of enclaves. Which I think of as the crown jewel servers behind firewalls (etc.), possibly with VPN or other gateways enforcing context-sensitive rules. So that’s perhaps an add-on to the above? (TBD. And now I’ll change the subject quickly…)
Staffing Implications
With effort, the underlying network may get simpler. And vendor tools may make managing that simpler.
For bigger organizations, some more advanced skills are needed to fully leverage Cisco DNA center or ACI. And ISE, for sure! I see ISE or ClearPass as one likely key component as things evolve.
Smaller organizations may not be able to afford, or may no longer need, a full-time senior networking person. But networking with security skills might fit? Alternatively, if you feel you’ll be under-utilized, there are always consulting firms and vendors.
Given that there is an extreme shortage of networking staff, job security seems unlikely to be a problem. However, it may require moving to a larger organization.
Conclusions
The above presented an extreme future network design (at a high level). Intent: to get you thinking.
NetCraftsmen would be glad to work with your organization, either to assess your network from the bottom up, discuss alternatives for the future, or to take a look at what you have and suggest how to simplify it.
By the way, I was reading an older Forrester report on Zero Trust Endpoints that seemed to slam VPN. I’ve found Cisco AnyConnect and F5 Big-IP to work rather smoothly lately. Some others do not work so smoothly (disconnect/reconnect cleanly, require the occasional reboot, etc.). YMMV. (FWIW, I’m finally working with a site and code version where Citrix remote access is not annoying me!)
