Posted on Jul 12, 2018
When the internet took off, it quickly became clear that the finite number of IPv4 addresses would soon be tapped out. The protocol allows for about 4 billion IP addresses, and there are already more than 4 billion connected devices—with many more on the way as a result of the adoption of cloud, the Internet of Things (IoT), and software containers.
Anticipating that shortage, IPv6 was introduced in 1998. With the potential for trillions of addresses, the number of devices that can be connected is virtually infinite. But don’t wait around expecting IPv6 to solve your problems. IP addresses function not only as an identifier but also as a locator, which is a frequent cause of IT headaches. The location function causes conflicts, adds to management overhead, creates security holes, and often raises availability issues.
In the meantime, network address translation (NAT) provided an acceptable workaround, as it allowed for a single public IPv4 address to accommodate multiple private IP addresses. But NAT creates a multitude of problems, ranging from the need to manually update port addresses to incompatibilities between NAT and IPSec. IPv6 eliminates the need for NAT because every device can have its own unique IP address. That makes for a more secure environment, although it creates its own headache of having to keep track of those unique addresses.
As Hans Proenen, Chief Information Security Officer at GE Europe, told ComputerWeekly:
Because there are so many IPv6 IP addresses, it is virtually impossible to do a scan of the network to find rogue devices, which makes securing an IPv6 network a lot more demanding.
Adoption of IPv6 has been relatively slow, but it’s starting to accelerate. For 2017, Google’s data on user access revealed a steady climb of IPv6 users from 16% at the beginning of the year to over 20% just past the midway point. But it’s a complex process, that involves upgrading, reconfiguring, and testing of the hardware and software. Worse, IPv6 doesn’t address the fundamental flaw of TCP/IP with addresses being used for both location and identity. This provides bad actors with essentially a roadmap to create mischief by targeting IP addresses of enterprises or individuals.
If you’re going to upgrade your internet addressing scheme, why not step outside the box and switch to an approved standard that relies on cryptographic identities? That’s the essence of the IETF-approved Host Identity Protocol (HIP), which separates the locator and identity elements of IP addresses and inserts a secure namespace that makes it possible to quickly and simply set up secure network overlays.
Check out this ESG Lab Report on how we’re commercializing HIP to relieve many of these IPv6 pain points!
Posted on Jul 10, 2018
[Exclusive Interview] VIP Jeff Hussey
Quoting Albert Einstein, Jeff Hussey said, “We cannot solve our problems with the same thinking we used when we created them.” He emphasizes that we need to think out of the box, which is easier said than done. Therefore, in today’s sharing session with the expert on creative thinking and breaking through cyber security myths, everyone should benefit and learn as much as possible.
Break the Old, Establish the New
Jeff Hussey’s creation of new things stems from his view of the cyberspace being “old”. “I started working in the bond trading sector, focusing on information trading. Therefore, I have to master network technology and I have found a problem." In the 1990s, the Internet grew at an incredible speed, doubling at a rate of 90 days. However, at the time, the Internet was a luxury; each server was very costly and also had a lot of problems. “To double your speed, you have to pay five times more. It was very expensive. Besides that, the server efficiency was low and unreasonable. Why not try load balancing?” Just one problem led to the breakthrough of the traditional server concept, resulting in the technological advancements of load balancing and the advent of F5.
Changing the Internet Fundamentally
F5 is the precursor to load balancing that changed the Internet forever. Do modern servers have load balancing? After F5's IPO in 1999, the stock price rose by 1,040% in 6 months. This story is now a classic, and with this, Jeff Hussey was also recognized as a legend in the field. But Jeff did not stop innovating; he discovered another revolutionary idea in 2014: Identity-Defined Networking (IDN). This time, it was an even more thorough and drastic change. "I think this idea is incredible. It is fundamentally changing everything on the Internet." Tempered Networks now views the Internet from a new angle. Defining networks with identity is completely different from the traditional definition of IP addresses, which may completely change the world of the Internet.
Situation: like treating cancer with a bandage
Jeff Hussey firmly believes that Tempered Networks can solve the problems of the current Internet world. "The fundamental problem with the Internet is that the current network protocol, TCP/IP, is older than I am! The inventor did not consider security and made a fundamental mistake: there was no distinction between locator and identifier." The inventor may not have thought that the Internet will grow to its current scale today, leading to chaos, serious security loopholes, and hacker attacks. "In today's world, you build networks, then the switch, and router... Afterwards, you think of security, so you add firewalls, VPNs, etc. Everyone spends a lot of time and energy solving these problems, but it is just like treating cancer with bandage. We need to solve the root of the problem." Tempered Networks' approach to this is to tackle the problem from another angle and solve the fundamental cause of the problem.
Solving a “problem”
Normally, when people solve problems, they find an answer. “Tempered Networks uses another approach to securely connect over the Internet, thereby addressing the root cause of security issues. Each device is defined as an identity from the very beginning, which can be communicated first, and thus no longer pose any IP address security issue.” The beauty of IDN is that the device does not have the inherent risk of using IP addresses for identity. There is no issue because the “problem” simply does not exist. “Communication between devices are safer and more secured because the hacker cannot even find you. And you don’t need to drastically change the infrastructure. It is very easy to configure and can be done in 10 minutes, after which it is set once and for all.”
Cybersecurity is a sport
"The online world will only continue to expand. If we do not fundamentally change the network protocol, we will not have enough manpower to deal with the bigger problems." Especially with the rapid development of IoT and cloud technology, the load on network security has become more severe. Jeff Hussey believes that Tempered Networks will allow businesses to allocate their IT staff to deal with more important things. His greater concern with the online world today is hackers. "Network security is not just a big business. It is a sport. In addition to money and profits, there are many people who are interested in it. It is just like climbing a mountain. Just because there is a mountain there, people want to climb it and challenge themselves. They will invade the railway system, public, and defense facilities, which can be really dangerous.” If Tempered Networks’ IDN can improve the cyberworld's security, it will be equivalent to removing the mountain so hackers will not have a mountain to climb. However, will new problems arise from that? "They can play other sports, e-sports are not bad," Jeff Hussey is the internet version of yugong yishan.
*This article was originally published on wepro180.com and has been translated from Chinese
Posted on Jul 3, 2018
Today, more news regarding surveillance cameras were under scrutiny as more vulnerabilities were exposed. These vulnerabilities were reported as CVE-2018-10658, CVE-2018-10659, CVE-2018-10660, CVE-2018-10661, CVE-2018-10662, CVE-2018-10663 and CVE-2018-10664. It was discovered that chaining three of any of the listed vulnerabilities together can compromise the cameras, allowing threats to be introduced into an IoT Ecosystem, providing pivot points for further malicious activity. IP surveillance cameras are easy targets for cyberthreats due to their low administrator involvement and constant connection to a network and the internet, making these types of exposures a cheap path for hacking.
The typical structure of an attack on IP surveillance cameras is modeled after the cyber kill chain. The attack can consist of reconnaissance or identifying the target and its vulnerabilities. Once proper information is gained, the IP camera is then weaponized; remotely installing malware and preparing the IoT device for command and control for the attacker’s objective. Two types of outcomes can occur with this unauthorized access; to cause damage and destruction or advanced persistent threats (APT) where bad actors are undetected for long periods of time with the intent to steal data, such as personally identifiable information.
Tempered Network’s Identity Defined Networking (IDN) solution can easily and securely segment your IoT ecosystem from your existing network, cloak your IP surveillance cameras from cyber-attacks and effectively make your cameras and other IoT devices invisible to hackers. Cloaking reduces the total attack surface area and eliminates the cyber kill chain at the Reconnaissance level, potentially eliminating the attack from further advancing. When your IP surveillance cameras are cloaked by Tempered’s IDN, they are not able to be scanned for IP addresses or running services. Hackers can’t hack what they cannot “see”.
Our IDN design objective is based on the principle that it must be easy to connect, cloak, segment, move, failover, and disconnect networks and individual resources. IDN unifies networking and security into a single platform, making it simple to create Zero Trust Overlays without having to modify existing network or security infrastructure. Our point-and-click management console makes it easy to connect, micro-segment and manage all your networked devices—across any transport or location. And this approach comes at a fraction of the cost of alternative solutions.
Building and managing secure identity defined networks is easier and more cost effective than you may think. For more IDN details and use cases to help secure your IoT Ecosystem and address your 2018 IoT cybersecurity challenges, please visit Tempered Networks.
Posted on Jun 28, 2018
We’ve heard it all before, right?
Headliners of network breaches of compromised financial and personally identifiable information. Cloud security challenges like securing unmanaged traffic, user bypass, IoT devices, and how to ensure data workflow resiliency? Then there are decisions like going with an API or proxy-based approach to security? Do we use Appliances or software? Where to find security unicorns to run it all? I can go on, but what I mentioned are just a fraction of the daily challenges you face in your roles as digital leaders, IT leaders, CSOs, and CISOs. These challenges and complexities are the stuff of nightmares that keeps you up at night…
Unless Tempered Networks’ Secure IDN has been deployed. Gone are the days when engineers create a network to get things conveniently connected first and then figure out how to secure said network. What it truly boils down to is this; Secure Identity Defined Networking from Tempered Networks helps you build inherently secure networks from the get-go. And, to relieve some of the complexities in your daily roles, IDN was designed to be done in a real simple manner; 3-clicks and you’re up and running.
Wait, what? Three mouse clicks and I not only have a network up and running, but a secure network based on identity of the devices I add to it? “What sorcery is this”, you ask? Let’s go over some data elements to better understand what Identity Defined Networking is and how it is secured.
Tempered Network’s IDN works as an overlay fabric to your current infrastructure (underlay) and is secured by the Host Identity Protocol (HIP), Encapsulating Security Payload (ESP), Zero Trust, Cloaking and Stateful Packet Inspection (SPI) Firewalls.
IDN provides a trusted Host Identity Namespace that serves as a unified networking and security policy enforcement across a single network architecture. The fabric still uses your host’s IP address for its network location but replaces the hosts IP address used as the host identity, with a HIP provided cryptographic ID to uniquely verify the machine’s identity. The IDN Fabric, or the Overlay’s perimeter, is defined by the hosts you add to the network overlay policy. This means that your secure overlay perimeter doesn’t have to encompass a whole network edge, the perimeter can be as restrictive as a single host.
One of the great things about IDN is there’s no need to change IP schema when the IDN components are installed in your network, but you can still use your own IP schema with global IP mobility and resiliency, free of IP and DNS limitations. Here are some additional definitions that will help better explain IDN and how it can help you defeat those night terrors.
Host Identity Protocol: An IETF ratified standard that replaces the IP address typically used for host identity with a cryptographic identity. HIP provides authentication and authorization based on the cryptographic identity prior to any transport and data exchange is accomplished through an encapsulating security payload.
The IDN Fabric consists of three levels of components; Orchestration, Enforcement, and Routing. Each of which can comprise of software, appliance, or both.
Orchestration: The Conductor allows the administrator to create, manage, automate policies, and trigger policy events to all Enforcement elements in the overlay.
Enforcement: The HIPservices that run on, adjacent, or inline to any host and acts as the overlay network policy and security enforcement point. Encapsulating Security Payloads are enforced by the HIPservices according to the policies the Conductor provides.
Routing: The HIPrelay is an Identity Based Router, a world’s first, that provides machine-to-machine connectivity between private or non-routable endpoints. The HIPrelay can also be used for ESP-resiliency - if your local secure HIPserver to HIPserver communication fails, the HIPrelay can be used as an ESP failover mechanism to keep communications alive.
Let’s bring the conversation back to what’s securing access to the IDN, like “cloaking”. Simply put, IDN cloaking is accomplished by adding your networked devices into the IDN fabric (also known as our Overlay). Once in our Overlay or behind one of our HIPservices, that device is no longer discoverable in your existing network (also known as the Underlay).
Zero Trust means that whatever you place in our Overlays, that network device will not be accessible by other devices outside of an Overlay Whitelist Policy, nor is it able to access anything beyond its Enforcer element (HIPservice) without a specific whitelist policy to do so.
Once a Network Overlay is created and end devices are added, more security can be achieved by deploying the Enforcer’s (HIPservice) SPI Firewall, restricting traffic to specific hosts and services.
Putting it all together, this is what a typical three click IDN deployment would look like:
The Underlay, your existing network.
The IDN Fabric is created with the Enforcement components – the HIPservices (HIPswitch Appliance, Virtual HIPswitch, HIPapp, or HIPswitch Cloud).
Devices removed from Underlay and added to Overlay. There is Zero Trust until an Overlay Network Policy is created for these devices.
Step 1: Create an Overlay Network Policy - each color (orange, green, purple) in the following diagram represents a separate Overlay Network Policy.
Step2: Add devices to the Overlay Network Policy – devices are added to each color coordinated Overlay Network Policy (orange, green, purple).
Step 3: Create Whitelist Policies between specific devices to allow communication and data sharing - the lines connecting the color coordinated devices represent ESP tunnels, which are allowed because of their Whitelist Policies.
In this scenario, there is Zero Trust between disparate colored Overlay Network Policies. Only orange devices can communicate with other orange devices, green to green and purple to purple. Unless a specific policy is created, the orange devices cannot communicate with the green, purple, or Underlay devices. This is also true for the green, purple, and underlay devices to each other. The underlay devices located in your existing network are still capable of freely communicating within the Underlay.
The Overlay (colored) devices are cloaked from the Underlay network and each Overlay device is cloaked from any devices enforced with a disparate colored policy.
The three steps to creating these secure networks are typically done manually, but with the Conductor’s API, these three steps and many other events can be accomplished with simple API calls.
There you have it, a 5-minute explanation of Tempered Networks’ Secure Identity Defined Networking. IDN capabilities may not eliminate all your nightmares, but it can eliminate some nightmares by safeguarding sensitive data, meeting compliance, and automatically revoking compromised devices. Your world is complex and with it comes complex decisions. IDN can help ease that complexity and help to increase productivity by giving you easy to manage micro-segmentation, unconstrained data and resource mobility through secure access control from anywhere with sub-second failover for data and workload resiliency. All manageable through the Conductor with great ease, no unicorns necessary.
Heltzel, Paul (2018, January 8). The 12 biggest issues IT faces today [Blog post].
Wall Street Journal (2018, May 29). What Keeps CIOs Up at Night? [Journal Report].
Douglas, Joshua (2017, September 13). 5 Problems That Keep CISOs Awake at Night [Blog post].
Posted on Jun 25, 2018
My great-grandma lived 93 years, long enough to get some great-great grandkids. She immigrated from Germany during WW I, had a really interesting life, and was full of wise sayings. As I think about cloud computing, which she was never around to see, two of her sayings come to mind. “All the fun’s in the gettin’ there” is sage advice for people rushing through life, but seems completely off for cloud computing, unless cloud migration is your profession or hobby. Mistakes in cloud networking are super hard to isolate from apps, diagnose and debug, not fun.
On the other hand, “Nothing good ever came easy” applies perfectly. In cloud migration projects, nobody thinks about the huge network redesign costs around money, time, and security. There are many promises but few examples of phased app migration to cloud environments. Try to find any that don’t involve significant refactoring (if not entirely rewriting) the app in the process. Rewriting the app (or re-architecting the network) is not migration.
Running in a lightweight VM like a container helps along with container orchestration, but when it comes to east-west communication within a single container host, you just don’t have a lot of control (after all, you may not have written all those apps yourself…who knows how they might affect each other, accidentally or on-purpose, if allowed to be on the same network that you can’t segment with familiar tools?). Perhaps even more challenging is that you must typically “lift and shift” a large complement of servers/services in one big step so they can communicate, because spreading them north-south over a WAN seems unthinkable.
Networking inside the cloud is a great big mystery. Cloud providers present an interface to virtual workloads that makes them “feel like” they are on a L2 or L3 network. We at least know that AWS and Azure keep the details private (presumably so they can change proprietary aspects later, and possibly to avoid certain exploits). In the cloud, certain networking “givens” do not apply, like whether the software-defined L2/L3 “switch” honors arp or routing requests for IP addresses outside the defined subnet. In other words, it’s hard to make a NAT gateway in the VPC that captures your protected device traffic. Fortunately, we have figured out how to do this in all three major cloud environments.
The latest 2.1.3 release of Tempered Networks Conductor and HIPservices is a profound step forward to organizations trying to migrate existing applications to the cloud. We make it easy to create segments from the existing larger network, and control precisely which systems can be in a given segment. The really magical part, though, is that a Tempered network can span data centers, service providers, and media link technology such as wires, WiFi, and cellular. Essentially, your connected things feel like they are on an unrestricted LAN even though they may be separated over the WAN, behind NAT or other tools designed to create perimeters that we Zero Trust-ers know don’t work anymore (we have the tools to prove it).
This flexibility let’s you migrate services from old to new networks, locations, and environments without having to worry about protocol semantics or network security. The entire virtual LAN is encapsulated and encrypted for you, orchestrated to all locations, and easy to manage by people that are not security or networking experts. And best of all, data path communication is point to point (and PCI compliant) rather than backhauled (and in some cases decrypted) in a proprietary cloud service that you must “just trust”.
Every time our engineering team adds a new gateway platform, we bring you the same point-and-click simplicity we did for physical things (we spun-out from a Boeing project protecting factory tools and robots on WiFi) and private virtual environments (ESXi, KVM, Hyper-V, etc.). We protect things that can’t be altered or protect themselves, and we can make bold claims about being the best at handling the “last mile” (or what I call the “forgotten last mile” for OT/SCADA networks -- they have to wait for the IT organization to decide their needs are a priority, and worth the risk).
In 2.1.3 we support AWS, Azure, and Google clouds, along with several flavors of Linux HIPserver (hint: run that in your container). Deploy HIPswitches in your legacy infrastructure, and also in the cloud(s) of your choice, and we can make it appear that your physical or virtual systems are on the same LAN as your cloud instances. You can define as many segments as you want, as granular as you want, and the HIPservices will figure it out. You only need to “burn” one of your precious elastic/public/external IP addresses on the HIPservice gateway. Because we use HIP, IP address or device location changes have zero effect on the communication / security policy you define in Conductor. Because HIPswitch gateways do NAT and SNAT, you can connect multiple VPCs or other environments with overlapping IP addresses into a single LAN. If you are already using Tempered, you know that the security policy IS the communication policy, and is defined in terms of your devices or servers, not their IP networking details.
Did I say clouds? Yep, plural. You can easily connect multiple VPCs (aka Virtual Networks) together with cloud HIPservices. Why would you want to do that? One obvious use case is DR (disaster recovery). Sure, you could pick multiple regions with one cloud provider, but one outage can span multiple regions, or take out your primary and DR site when a common infrastructure component fails. A single cloud vendor is only acceptable now because the status quo says it would be too complicated (thus error prone and insecure) to manage the peculiarities of multiple vendors. Forget the scripts, just look at the screenshots in this…I rest my case.
The user-experience of a single cloud portal (pick any of AWS, Azure, Google) is … not simple. You need to be fairly technical and patient (and have a Rosetta Stone) to deploy and manage anything significant through their UI. This problem helped spawn numerous companies (like one down the street from us in Seattle), along with their own tooling and/or clouds, and countless armies of consulting experts to help you figure it out. So painful. Don’t expect the cloud providers to change soon; there’s a natural vendor lock-in for DevOps teams that know one cloud environment better than the others.
Tempered is all about simple. We tried to deploy HIPservices instances in VPCs using cloud provider portals, and it was way too complicated for us (despite several of us innovating in networking for 20+ years). How could we expect our customers, who have better things to do than waste brain cells learning complex UI and single-vendor concepts to figure out cloud networking? Heck, we even had a major city fire department ask us to clarify what we meant by “AWS” (but they can sure fight fires). So in 2.1.3 we orchestrated the entire thing inside Conductor! One simple workflow that applies to all cloud providers.
You create a provider for each of your cloud(s) with your credentials (e.g. project ID, client email, API secret). Then, you create a HIPservice template for each provider; we put a lot of work into retrieving all valid/necessary choices for machine type, region, zone, image id, network configuration, etc., from each provider’s API, so you don’t have to!
Once your providers and templates are set up, all you need to do to protect a VPC is Create HIPservice from the Conductor HIPservice page, select the provider + template, override any defaults if you wish, and then sit back and watch. The Conductor will take care of everything: Create the HIPservice in your cloud, connect it to the right subnet(s), reconfigure the network so the cloud servers are now using the HIPservice as a gateway to the Internet, and even take extra steps to secure your VPC now that you are protecting it with HIP! Since this may take a while in a cloud environment (typically 2-5 minutes), the Conductor will show you progress specific to that cloud environment. If you have ever tried to navigate the several lists, pages, links, and workflows to set up your VPC instances, security, subnets, routing, etc., you will probably be smiling. After you watch all this orchestration complete, try to ping from cloud to prem, to ESXi to the other cloud, and to the HIPclient on your laptop or phone. With HIPrelay, you won’t even need to worry about who initiates the connections, WAN routing, or firewalls. You could even ping from your cloud instances into your phone running the HIPclient with only a cellular connection. HIPrelay...another blog topic.
But wait, there’s more. With smart device groups, the Conductor will configure the new HIPservice in your cloud with communication policies, defining the segments of devices that are able to communicate whether they are in the cloud, on prem, in virtual environments, or even in a totally separate cloud provider. Diverse environments add no additional policy management complexity (which is the root of security problems -- another blog topic). And if you merely connect or disconnect any devices in a cloud environment, the Conductor will update the routing tables in your VPC(s) as necessary, automatically, without you having to worry about it. This is true WAN micro-segmentation, a cornerstone of the Zero Trust (*) architecture. Communication policy remains point and click, regardless of the crazy complexity of the networking environments where your devices run. That is the Tempered promise…one we aim to keep forever.
(*) rollout/migration recommendations in the article don’t consider that innovations such as a HIPswitch can be used as a gateway for legacy/non-cloud equipment, achieving a close approximation of Zero Trust for old systems whose network stacks can’t be altered.
p.s. Spoiler alert…we are adding a “provider” for OpenStack to Conductor in the next release cycle, which will require zero change in your workflow to be able to connect OpenStack, ESXi, AWS, Azure, Google, laptops, mobile devices, and on prem equipment into virtual private LAN segments.
Posted on Jun 20, 2018
Lucas has been one of our Support Engineers at Tempered Networks for over two years. While two years may not be a lot in the grand scheme of things, it could be converted to two decades at a tech start-up! Basically, he’s just seen a lot. I was able to tear Lucas away from his desk for a bit to ask him a few questions.
Q: Were your expectations different from when you first started this job?
A: In all honesty, I’m not really sure what my expectations were. The part I love about working for Tempered is that I’m not just a “support” guy. Everyone is very collaborative here, and I’ve been involved in helping make decisions to benefit our product and customers.
Q: What’s your favorite part of your job?
A: Every day is something new. That’s a good thing. I get to work on something different every day. I enjoy the challenges and learning of this job and Tempered gives me the opportunity to do so. It’s nice that my role is pretty in between Product Development and Sales. Even though a majority of my job is more customer-facing, I feel like I’m more engineering-focused and work with Sales less than you’d think. I take input and consideration from customers to help translate that to our Dev team.
Q: What has been your favorite “A-ha!” moment here?
A: I always enjoy learning something new during the troubleshooting process. The “A-ha” moments happen when I get to do a deep dive on how our product operates. I’ve had several cases where understanding the customer’s network environment allows me to provide solutions to the behavior they are seeing.
Q: Are there any fun facts about you?
A: I have a company nickname – L2. It’s a shorthand way of referring to me. And the best part, it’s a networking nickname, since we’re a networking company.
Q: What do you do in your free time?
A: What I do for work is as much a vocation as it is a hobby. I go e-waste scavenging. I brew beer with friends, more so because I enjoy the process rather than drinking beer. I like to travel, and I just came back from a trip to France and Switzerland. Austria was the year before, and I’m keeping my eyes open for travel deals for the next trip!
Thanks for sharing some of your experience and insight, Lucas!
Posted on Jun 14, 2018
Business professionals outside of IT demand business agility. It’s the current buzzword and has a nice ring… business agility! If you’re in IT, however, you’ve likely come to loathe the word. It’s very meaning conflicts with your need for tight security in the face of growing threats. Business agility requires quick and responsive implementation of whatever is needed to take advantage of business opportunity today, now, right away! But that runs headlong into the management of network access and security policies. Automation and orchestration are the keys to overcoming this conflict, but the inherent flaws of IP networking are the fly in the ointment, the roadblock to agility.
The 2017 Network World’s State of the Network report cited protection from data breaches and leaks as the top network security challenge across both enterprises and small to medium-sized business IT decision makers. The main reason network security in this area is so challenging is the lack of automation coupled with understaffed IT security personnel.
Another part of the problem is that IP addressing is being used to an extent that is magnitudes beyond what its inventors intended. A Washington Post article – A Flaw in the Design – points out the Internet’s founders “saw the promise but didn’t foresee users attacking one another.” At the end of the day, nobody foresaw the need for cybersecurity. By implementing the TCP/IP protocol to make it easy to find computer devices, it became easy for malicious users to attack devices—they could use IP addressing not only to locate and identify another device but also to spoof their own addresses to make it difficult to deflect an attack.
As industry analyst Zeus Kerravala states in the Network World article – Tempered Networks Makes it HIP to Connect the Unconnectable:
Since it’s impossible to give every device its own unique IP address, the clever folks at networking companies came up with an assortment of workarounds, such as being able to NAT (network address translation) non-routable, private addresses. And as we’ve added more dynamic environments, such as private and public cloud, defining policy based on addresses or ranges has become unsustainable.
In 2015, the IETF ratified a new addressing standard as an open networking security protocol designed to overcome the inherent flaws of TCP/IP addressing: The Host Identity Protocol (HIP). Implemented commercially with our Identity-Defined Networking (IDN) products and solutions, HIP makes it possible to create secure network overlays based on cryptographic namespace identities easily.
The IDN orchestration engine – Conductor – makes it possible to create hub-and-spoke or highly distributed mesh networks without the traditional network challenges. The result is an end-to-end or peer-to-peer encrypted network that can be spun up in as little as three steps, even for traditionally non-routable endpoints.
The simplicity of IDN means that IT teams can now deliver business agility to meet the demands of their business and IT operations team. Like today, now, right away!