Month: January 2020

PKIFNE #12: Diffie Hellman Groups

~ Steven McNutt ~ Leave a comment

Greetings programs!

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.

Key points

  • 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.

Operations

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:

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.

Quick hits: Taking control of emotions

Thinking about thinking
~ Steven McNutt ~ Leave a comment

Greetings programs!

I recently took a course on critical thinking, and I would like to share a couple of ideas about working with emotions and using them as a diagnostic tool.

Thinking about thinking
Thinking about thinking

Think—>Feel—>Want

If we look at how the human mind works, we can simplify the order of operations down to three steps:

  • Thinking
  • Feeling
  • Wanting
Credit: ‘Critical Thinking’ By Richard Paul and Linda Elder

The implications of this are rather profound. If our emotions are driven by our thoughts, it follows that we can change our emotional experience of the world by changing our thinking.

It further follows that if we’re having emotions that don’t seem particularly helpful, such as a generally negative outlook, than the key is to examine the thinking that led to those feelings. Which brings us to the second idea.

Check your assumptions

Assumptions represent our implicit beliefs about the world, and they are usually subconscious in nature. We use assumptions to rapidly interpret and make decisions. This pretty helpful in a situation where we need to react immediately such as taking evasive action to avoid a car accident. They are less helpful when they are used to make judgments based on a perspective or situation that’s no longer relevant, such as being an adult instead of a child.

Credit: ‘Critical Thinking’ By Richard Paul and Linda Elder

If we want to evaluate our thinking, and we know that our thinking is driven by subconscious assumptions, we have to find a way to bring those assumptions to the surface so we can take a look at them. How can we do that? We can ask questions!

Questions we might ask:

  • What is the goal of this thinking? What problem am I trying to solve?
  • What questions am I trying to answer?
  • What facts do I have?
  • What perspective am I looking at this from?

Putting it together

Once we’ve brought these assumptions to the surface, we can decide if they’re relevant and make sense. If they are, we now have an explicit reason and supporting argument to underpin our thinking.

If our assumptions don’t hold up, and we have no good supporting facts or reasons behind our thinking, then we can go back and look at the purpose of the thinking and see if it makes sense to reframe things in a way that can be supported by facts or reasons.

  • Maybe I’m just tired or hungry.
  • Maybe it’s something I can’t control and I have to let go.
  • Maybe it’s an unhealthy a situation I need to extract myself from
  • Maybe I need to look at this from a different perspective

Wrap up

Welp, that’s it for today. I hope was interesting and/or useful, and I’ll see you around.

-s

Children of the Magenta Line

~ Steven McNutt ~ 1 Comment

Greetings programs!

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.

Flock of birds wheeling around a statue of the barefoot mailman

Have a good one, and I’ll see you around.

-s

Quick hit: playing with Terraform & IOS-XE Day 0 automation

~ Steven McNutt ~ Leave a comment

Greetings Programs!

Over the last week or so I’ve been working on an Infrastructure as code Azure Hybrid cloud deployment, based on the Azure Spoke and Hub reference topology.

The gateways connecting Azure to the On-Prem datacenter in my case are Cisco Cloud Services Router 1000v (CSR1kv), using day 0 automation to inject a configuration into the Azure Router.

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.

Terraform Description file example

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.

Azure Cloud Shell – Checking the Terraform Version

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.

Best regards,

-s