IP networks were originally designed to be fairly simple. There’s a source and a destination address, and the network devices use this information to perform some fancy calculations—and magically, things connect.

But as the internet has grown and more endpoints have been connected, networking has become a black magic. 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.

For example, a business may have thousands of devices and only a few public IP addresses. At this point, the business has a couple of options. The first is to only connect the number of devices for which the business has available addresses. This certainly seems impractical.

The second option is to address all the devices with private, non-routable addresses such as 192.168.X.X and then perform NAT when broadcasting to the internet. But multi-NAT environments, as well as Carrier Grade NAT, make it impossible to punch through and connect distributed systems. IP address limitations further restrict what can be done with regards to critical functions, such as cloud peering preventing the easy movement of workloads between VPCs, as well as between clouds.

This may seem hunky dory, but what happens if that business buys another company that uses the same private IP addresses? Or perhaps there are multiple groups in the business working with Amazon, and the virtual instances both use the same addressing scheme and they need to be connected. Then what’s a network manager supposed to do? One solution could be to readdress everything, but there is no guarantee that there won’t be a similar conflict in the near future.

Tempered Networks’ HIPRelay to the rescue

Tempered Networks now offers a better solution.

Earlier this month, the company announced an enhancement to its Identity-Defined Networking (IDN) solution called the “HIPrelay” that solves this problem. HIPrelay is an identity-based router (versus address-based) that uses the recently IETF-ratified Host Identity Protocol (HIP) to connect private and non-routable IP resources to other networks. This includes any client, server, virtual machine, IoT endpoint or cloud instance on any public, private, mobile or cloud based network. The protocol abstracts the IP address and uses cryptographic identities to encrypt and secure traffic while overcoming the limitations of address-defined networks, including multi-NAT, CGNAT and cloud peering.

The HIPrelay lets businesses instantly connect any IP endpoint to any other regardless of location or addressing scheme, overcoming connectivity barriers such as NAT and restricted cloud-peering, while applying micro-segmentation, device isolation, containment and control for better security.

The Tempered Networks solution is a pure, non-disruptive overlay to the existing network that greatly simplifies and secures all connected endpoints regardless of how it is connected. The IDN effectively acts as a Star Trek-like cloaking device for network segments, making them invisible to hackers, Romulans or other bad guys by reducing the number of attack vendors.

And, just like Star Trek’s Transporter, the IDN directly connects one resource to another overcoming traditional limitations of point-to-point transport. Only devices possessing secure identities may join the overlay transport.

Because the solution operates as a software overlay, the network will become more agile and enable changes to be made faster while maintaining security policies. Cloud peering limitations, such as number of peering connections, regional restrictions and even cross-cloud peering are now removed. So instead of 150-plus configuration steps to create an edge-to-edge peer, you can now have instance-to-instance peering, making DevOps more agile.

The HIP protocol allows for the security and network perimeter to be moved from the network edge all the way to the host, creating a fabric of hardened, dynamic micro-perimeters that surround each host without having to modify the underlay. Only endpoints that are authenticated and authorized can communicate within an overlay segment, creating a fully isolated, hardened network zone that is operationally much simpler because there is no reason to use things such as NAT/PAT, VLANs, layer 3 VPNs and static routes.

LAN and WAN segmentation based on host identity

Tempered’s HIPrelay can be deployed and distributed across the internet, enabling businesses to scale their networks horizontally and making it easy to segment a LAN or WAN based on confirmed host identity. This improves geographic performance, but also security and compliance because traffic flows can now be isolated and contained within a country based on the cryptographic identity of machines, not ephemeral IP addresses.

The solution should pay big dividends for organizations looking to simplify cloud networking. Doing something such as peering Amazon Web Services (AWS) and Microsoft Azure at the network edge is not easy and requires hundreds of configuration steps to resolve IP addressing conflicts and peering challenges. Because HIP uses identity for network connectivity, cloud instances can be directly connected to other instances that can traverse the AWS or Azure edges. Also, DevOps engineers can skip the use of things like SSH, shared keys or VPN connections because they will have direct access to any VPC-based instance.

The rise of the cloud, mobile computing and IoT are making networks increasingly more complex. Trying to connect resources using traditional workarounds wastes a significant amount of network operations team’s time. However, taking a step back and having to re-architect the entire network can be painful and time consuming. Tempered Networks IDN platform based on the open HIP standard enables wide-area micro-segmentation, without the age-old network barriers of address-defined networks.