It’s been quite some time since I’ve posted anything, so let’s do a thing.
This is a whitepaper I wrote about ten months ago that grew out of an effort to establish a foundational, functional, understanding of what zero trust looks like. I know the term is being overloaded to mean all kinds of things which is a bummer. Anyhow, here’s an honest and hopefully useful take. I backed my assertions with citations and all that sort of stuff. If you want to go down the rabbit hole it’s all there in the bibliography, and it’s some great reading to be honest. I invite you to dig a little deeper and check out some of that material.
Also, you know what? Using big honking firewalls to macrosegment legacy application traffic in on-prem datacenters is totally fine and valid don’t @ me. 🙂
It’s been quite a ride for the last month or so, so much going on. Last Monday morning I passed the new Cisco DEVASC exam (200-901) on the first day to test, making me a member of the Devnet 500 club.
Preparing for the exam really did a lot for sharpening up some relatively new skills I’ve acquired that haven’t had a lot of reinforcement. That’s the real value of IT certifications – having that performance-based focal point. When your learning is self-directed there is a real tendency to sort of wander from topic to topic and lose focus, and learning tracks are a great tool to combat that.
That said, I think the most important takeaway is that we’re rapidly transitioning to an API driven world and it’s important to get comfortable working with structured data and logical abstractions in general regardless of the job role.
Ok, about Terraform. What I’m working through is the approach I want to take. I want to bring a unique angle rather than join a chorus of people all saying and doing the same thing. If there are specific things you would like to see, let me know in the comments.
Life has gotten a bit hectic recently, and will likely remain so for another couple of weeks. Small things are beginning to take conscious effort and focus which is a reliable indicator that I need to trim the sails a little. What this means for this space is the first Terraform post is delayed for a week, possibly two.
On a brighter note, the weather was wonderful for this morning’s walk, my dogs were well behaved, and coffee is always there for us and wants us to be happy.
Until next time, may you care for yourself with ease.
Today’s post is an excerpt from my CCIE Security notes, and it has a useful table of Diffie Hellman groups, which you can use as a job aid in IPSEC VPN designs. I Hope you find it useful.
About Diffie Hellman
The key bit of magic that makes IKE (Internet Key Exchange) possible is Diffie-Hellman. Diffie-Hellman allows anonymous entities to calculate a shared secret that can’t be discovered by a third party listening to the exchange. What’s amazing about it is the peers are able to do this using two different passwords that they keep private and never exchange. DH is one of the earliest examples of Public Key Cryptography.
Diffie-Hellman does not provide authentication. It’s used to assist in creating a secure channel for authentication
Diffie-Hellman does not provide encryption. It provides the keying material for encryption.
Diffie-Hellman is used for control plane functions only.
At a high level it works like this:
If side a and side b use the same generator and modulus, resulting values from step 5 and 6 should be the same. This shared key is used as an input to the negotiated encryption algorithm.
In the case of Diffie-Hellman The generator and Prime (g,p) are predefined values (defined in a number of different RFCs) which are referenced as Diffie-hellman groups. The larger the Generator and Prime are, the more difficult it is to break. As computational power has increased substantially since the first DH groups were defined, the old groups are no longer safe to use.
The following Table lists the Diffie-Hellman Groups:
*NGE refers to Cisco Next Generation Encryption, which is the vendors set of recommended ciphersuites.
*NSA Suite B refers to the United States the National Security Agency’s published list of list of interoperable modern cryptographic standards.
I believe it’s a safe assumption that the current crop of budding network engineers are being indoctrinated with the notion that if they don’t 100% automate all the things, their jobs and careers will be at risk. My friend Daniel Dibb deserves ample credit for repeatedly asking the question “What happens when we subsequently end up with a generation of automation engineers who don’t understand networking?”.
Yesterday morning I was drinking coffee, scrolling through my Twitter feed, when I came across a thread where Marko Milivojevićposted a link to a youtube video of American Airlines Captain Warren Van Der Burgh, delivering a talk in 1997 called Children of the Magenta Line. The context is lessons learned from a rash of airline crashes caused by flight crews becoming too dependent on automation.
If you are an infrastructure engineer, or you manage infrastructure engineers, this video is worth 25 minutes of your time.
There are two quotes that stand out from this Video:
We are Pilots and Captains, not Automation Managers
You’ve got to pick the appropriate level of automation for the task at hand
In googling the name of the video, I came across this article which had a quote from William Langewiesche which also illustrates a fundamental problem with over reliance on automation:
“We appear to be locked into a cycle in which automation begets the erosion of skills or the lack of skills in the first place and this then begets more automation.”
Let’s learn from the Airline industry and not repeat their mistakes.
Here’s a link to the Azure Deployment Guide for the CSR1kv, which has some really interesting tidbits. I’ll dive into those in future post.
To actually execute the infrastructure build, I’m using a tool called Terraform.
Terraform does an incredible job of abstracting away all the details you normally have to worry about when provisioning cloud provider infrastructure. It’s a joy to work with. The documentation and examples are easy to follow, and the error messages tell you exactly what you did wrong and where to look.
If that wasn’t cool enough, the Terraform binary is actually built in to the Azure Cloud shell. The net of that is, once you have your deployment files built, you can work with them using just cloudshell, which is super convenient.
That’s it for today. Lot’s of neat stuff in this lab that I’m dying to talk about, can’t wait to share.
Holy cow, been 8 months since my last dispatch. Still studying and learning cool stuff, have not done a good job at stopping to document my learnings, going to make another attempt to rectify that.
Been an eventful year. In addition to learning DevOps tools and techniques and studying cloud native software design, I’ve also changed jobs. As of August I’ve been working at Cisco systems as a pre-sales Architect. It’s a dream job and I absolutely love working with my customers. I learn as much from them as they learn from me.
So yeah, the new job thing; several months of getting the firehose and struggling to take everything in and find my stride.
I didn’t feel like that was enough new stuff, so I enrolled in WGU’s Cybersecurity Bachelor’s program starting in January. I don’t **need** a degree, but I don’t think it would hurt to become a more well-rounded technologist. I’ve historically used certifications for learning paths which is fine but they tend to be narrowly defined in scope which can lead to polarized thinking.
So here’s the plan for the blog: I’m committing to posting something every Monday morning, even if it’s just a “hello, I’m drinking coffee and checking my twitter feed how about you”. I have a sizable collection of study notes, so there’s no shortage of meaningful topics however. Hopefully I’ll dip into that more than the small talk :).
Have a great week, talk to you next Monday morning.
In the next few PKI for network engineers posts, I’m going to cover Cisco IOS CA. If you’re studying for the CCIE security lab or you’re operating a DMVPN or FlexVPN network, and you’d like to use Digital certificates for authentication, then this series could be very useful for you.
IOS-CA is the Certification Authority that is built into Cisco IOS. While not a full featured enterprise PKI, for the purposes of issuing certificates to routers and firewalls for authenticating VPN connections it’s a fine solution. It’s very easy to configure and supports a variety of deployment options.
Comes with Cisco IOS
Supports enrollment over SCEP (Simple Certificate Enrollment Protocol)
RSA based certificates only
Easy to configure
Network team maintains control over the CA
Solution can scale from tiny to very large networks
IOS-CA has the flexibility to support a wide variety of designs and requirements. The main factors to consider are the size of the network, what kind of transport is involved, how the network is dispersed geographically, and the security needs of the organization. Let’s briefly touch on a few common scenarios to explore the options.
Single issuing Root CA
For a smaller network with a single datacenter or a active/passive datacenter design, a single issuing root may make the most sense. It’s the most basic configuration and it’s easy to administer.
This solution would be appropriate when the sole purpose of the CA is to issue certificates for the purpose of authenticating VPN tunnels for a smaller network of approximately a hundred routers or less. Depending on the precautions taken and the amount of instrumentation on the network, the blast radius of this CA compromise would be relatively small and you could spin up a new CA an enroll the routers to it fairly quickly.
The primary consideration for this option is CA placement. A good choice would be a virtual machine on a protected network with access control lists limiting who can attempt to enroll. The CA is relatively safe from being probed and scanned, and it’s easily backed up.
Offline Root plus Issuing Subordinate CAs
For a network that has multiple datacenters and/or across multiple continents it would make more sense to create a Root CA, then place a subordinate Issuing CA each datacenter that contains VPN hubs. By Default IOS trusts a subordinate CA, meaning the root CA’s certificate and CRL need not be made available to the endpoints to prevent chaining failure.
As in the case with any online/Issuing CA, steps should be taken to use access controls to limit access to HTTP/SCEP
Issuing Root with Registration Authority
In this design, there is still a single issuing root, however the enrollment requests are handled by an RA (Registration Authority). An RA acts as a proxy between the CA and the endpoint. This allows for the CA to have strict access controls yet still be able to process enrollment requests and CRL downloads.
Offline Root & Issuing Subordinate CAs w/RA
The final variation is a multi-level PKI that uses the RA to process enrollment and CRL downloads. This design provides the best combination of security, scaling, and flexibility, but it is also the most complex.
Bootstrapping remote routers
Consider a situation where you’re turning up a remote router and you need to bring up your transport tunnel to the Datacenter. The Certification authority lives in the Datacenter on a limited access network behind a firewall. In order for the remote router to enroll in-band using SCEP, it would need a VPN connection. But our VPN uses digital certificates.
There are three options for solving this:
Sideband tunnel w/pre-shared key
This method involves setting up a separate VPN tunnel that uses a pre-shared key in order to provide connectivity for enrollment. This could be a temporary tunnel that’s removed when enrollment is complete, or it could be shut down and left in place for use at a later time for other management tasks.
A sideband tunnel for performing management tasks that may bring down the production tunnel(s) is useful, making this a good option. It’s main drawback is the amount of configuration work required on the remote router. It also depends on some expertise on the part of the installer, a shortcoming shared with the manual enrollment method.
A Registration Authority is a proxy that relays requests between the Certification Authority and the device requesting enrollment. In this method an RA is enabled on the untrusted network for long enough to process the enrollment request. Once the remote router has been enrolled the the transport tunnels will come up and bootstrapping is complete.
Using a proxy allows in-band enrollment with a minimum amount of configuration on the remote router, making it less burdensome for the on-site field technician. The tradeoff is we’re shifting some of that work to the head end. Because the hub site staff is likely to possess more expertise, this is an attractive trade-off.
In this method, the endpoint produces a Enrollment request on the terminal formatted as base64 PEM (Privacy Encrypted Mail) Blob. The text is copied and pasted into the terminal of the CA. The CA processes the request and outputs the certificate as a PEM file, which is then pasted into the terminal of the Client router.
While this does have the advantage of not requiring network connectivity between the CA and the enrolling router, it does have a couple of drawbacks. Besides being labor intensive and not straightforward for a field technician to work with, endpoints enrolled with the terminal method cannot use the auto-rollover feature, which allows the routers to renew certificates automatically prior to expiration. The author regards this is an option of last resort.
CRL download on spokes problem
The issue here is when the spoke router needs to download the certificate revocation list (CRL) but the CA that has the CRL is reachable only over a VPN tunnel, that cannot come up because the spoke can’t talk to the CA to download a unexpired copy of the CRL in order to validate the certificate of the head end router.
This is actually a pretty easy problem to solve. Disable CRL checking on the spoke routers, but leave it enabled on the hub routers. This way the administrator can revoke a router certificate and that router will not be allowed to join the network because the hub router will see that it’s certificate has been revoked.
Ok, so there are the basics. In the next installment, we’ll step through a minimum working configuration.
Hard to believe it’s been a year since the last update. Time really flies doesn’t it?
I’ve maintained a study schedule, however it’s been oriented around topics that don’t make any sense for a technical blog. That’s going to continue for a time, but I’m also bringing relevant topics back into the mix. This means more regular updates here (yay!).
In addition to straight technical content , I’ll be adding some context and high level overview type things. This is my way of processing and participating in the ongoing community dialog about learning, skill stacks, and general professional development.
There are a lot of exciting things going on and not enough hours in the day. I feel like a kid in a candy store when I get up every morning. Let’s get to stuffing our pockets shall we?