Skip to content

Sample Use Cases

MarconiAdmin edited this page May 16, 2019 · 32 revisions

Overview

Below you can find sample use cases that can be solved using Marconi Protocol:

Connecting Hybrid Clouds

The Problem

If your organization is using cloud hosted services today, there's a good chance that you're using more than one provider. Sometimes this is because a single cloud provider is missing important products or services so some mixing and matching is required. In other cases, the motivation is cost driven because not all providers have the same pricing. Other organizations may bring another cloud provider into the fold to reduce their dependence on a single provider.

No matter the reason that necessitates a multi-cloud or hybrid setup, the networking challenges that are associated with it are almost always the same. Instances in each cloud provider are typically in their own private network and can't see each other (let alone communicate) without significant routing or firewall configurations. Each instance essentially lives in a silo without any interconnection. If the instances do get bridged, it's an entirely different challenge to make sure that communication is secure and safe from attacks such as eavesdropping or man in the middle.

How is this solved today?

Multi-Cloud setups are increasingly popular so people have certainly tried to tackle some of these issues. If there are sufficient resources, some teams spin up NAT's or VPNs to try and bridge each network, but that means there's one more service to configure and maintain and yet another point of failure. VPNs, created for the age of static data centers, rather than the elastic topologies that cloud hosting enables, don't always scale well depending on how many different sites are being bridged. Additionally, if your VPN setup funnels all traffic through a single corporate headquarters as many do today, then there could also be extra latency involved as traffic is forced through an extra hop. All of these solutions typically require additional hardware or complex configuration changes. Some cloud providers like AWS offer their own solutions like DirectConnect, but these all come at an additional cost.

Kubernetes was developed to abstract away some of the challenges of working with multiple cloud providers, but still suffers from networking challenges. Istio, a Kubernetes service mesh designed to streamline inter-service communication, was developed at higher layers of the networking stack and is only now adding support for things like UDP traffic.

Connecting with the Marconi Protocol

The Marconi Protocol offers a much simpler software based solution for bridging cloud providers into a flat network where each node can securely peer with every other node in the network, regardless of geographic location, cloud provider, or even whether it's a shared/dedicated/container instance. It's now possible possible to create and manage an overlay network that is completely agnostic of the underlying network architecture. Additionally, each Marconi Network has a built in DHCP server which creates a private IP address for each node in the network to peer as if they are sitting right next to each other in the same data center. Marconi's support for mesh networking enables peer to peer connections to minimize latency and all communication is secured end to end which eliminates the need for a separate VPN.

Steps for Bridging Cloud Providers

Only OpenStack cloud providers are supported for this use case right now. If you're using AWS additional documentation will be released shortly for bridging AWS and other cloud providers.

  1. Firewall Setup

    1. Ensure that the following ports are open on each cloud instances
      • TCP: 24802, 28902, 10004, 23200, 24000-31919, 22
      • UDP: 24000-31919
        • Depending on which cloud provider you're using this may not be necessary. Refer to this guide to lookup the cloud provider that you're using today.
  2. Node Setup

    1. Follow the setup instructions to install Marconi on each cloud instance.
    2. Make note of the nodeID that is created for each node so you can add that to the network in the following steps.
  3. Network Setup

    1. Create a network using this guide. Reference the nodeID from Step 2 when adding nodes to your new network.

Protecting Online Activity

The Problem

Protecting online activity is becoming more essential every day. This is particularly true for journalists in hostile countries, but it's even true for your typical user just trying to live their life. Public Wifi is notoriously dangerous and with the repeal of net neutrality ISPs are now free to collect and sell data about your browsing activity. It's also a very sensitive topic for anyone operating blockchain nodes. Recently an Ethereum core developer called out how the light clients that many people use to connect to the network depend on a discovery protocol which can reveal IP addresses to anyone who's looking. As worrisome as this is there is (some) hope.

How is this solved today?

Today, most people are familiar with VPNs and how they can help protect your anonymity online. These services, which can be paid or free, route user traffic through an encrypted connection to the VPN provider's servers so that the users actual IP address is never revealed. But while they are often touted as a solution to user privacy, they aren't without their own issues. A recent study by TheBestVPN showed that of the top 115 VPNs, 26 of them collect personally identifiable information like your IP address, location, bandwidth data, and connection timestamps. In other cases, VPNs (especially the free ones) sell user data and in some of the more appalling cases, VPNs have been shown to sell their customers bandwidth to 3rd parties like hacking groups which turn unsuspecting users into botnets.

Marconi Gateways

The Marconi Protocol enables anyone to quickly and easily spin up their own secure gateway which essentially acts like a VPN. Since the user is managing everything there's no need to place any trust in a 3rd party VPN provider who may be logging data or worse behind the users' back. Like a VPN, all user traffic is routed over a secure connection (in this case a Marconi Pipe protected with 256-bit mutating encryption) to a separate exit node which protects the user's original IP address. As an added bonus, this exit node can be hosted inside of a datacenter which may actually result in a performance increase since all user traffic can now traverse the high speed connections employed by most datacenters.

Steps for creating a Marconi Gateway

  1. Set up an offsite server which will act as the exit node for user traffic. Cloud instances can be set up quickly, but a server within a datacenter may provide greater performance.

  2. Set up a local machine (e.g. laptop, desktop, etc.) who's traffic you want to protect.

  3. Firewall Setup

    1. Ensure that the following ports are open on the local machine and exit node
      • TCP: 24802, 28902, 10004, 23200, 24000-31919, 22
      • UDP: 24000-31919
        • Depending on which cloud provider you're using this may not be necessary. Refer to this guide to lookup the cloud provider that you're using today.
  4. Node Setup

    1. Follow the setup instructions to install Marconi on the local machine and exit node.
    2. Make note of the nodeID that is created for each node so you can add that to the network in the following steps.
  5. Network Setup

    1. Create a network using this guide. Reference the nodeID from Step 4 when adding nodes to your new network.

Connecting Branch Offices

The Problem

Many businesses today operate from multiple locations. These can be retailers, restaurants, or service companies that operate locations in the same market. Corporations, of course, also have multiple locations and it's only becoming more common. With the increase in globalization many companies opt to have local offices to better understand the market. Companies based in major cities may opt to open offices in other regions with lower cost of living and less competitive labor markets. The rise of remote workers has also motivated a large shift to a world in which there's no longer a single office. With all of the branch offices opening there's a greater need to securely connect them in a way that's easy to manage and can rapidly scale as more branch offices open.

How is this solved today?

Previously, businesses connected their branch offices with fiber connections, but these are expensive, take months to install and require long term contracts. Today, more and more organizations are taking advantage of the public internet and technologies such as VPN and SD-WAN to connect their branch locations. However, many of these solutions require expensive hardware or licenses to setup and maintain or have so many options that it's possible to inadvertently open a security hole due to a simple misconfiguration.

Connecting with the Marconi Protocol

The Marconi Protocol offers a simple solution for connecting any number of branch offices. With the Marconi Protocol, each connection is secured with mutating AES keys for extra security and can be configured as a mesh network for greater resiliency in case a hub goes down. All endpoints are secured with asymmetric key identities keys instead of usernames & passwords which can be easily cracked.

Steps for Connecting Nodes

  1. Firewall Setup

    1. Ensure that the following ports are open on each machine
      • TCP: 24802, 28902, 10004, 23200, 24000-31919, 22
      • UDP: 24000-31919
  2. Node Setup

    1. Follow the setup instructions to install Marconi on each node.
    2. Make note of the nodeID that is created for each node so you can add that to the network in the following steps.
  3. Network Setup

    1. Create a network using this guide. Reference the nodeID from Step 2 when adding nodes to your new network.

Securing Blockchain Deployments

The Problem

There are multiple ways to contribute to your favorite blockchain project whether it's mining, staking or operating nodes (masternodes, full nodes or lightweight nodes). Regardless of what you're doing, these private deployments require an investment of time, money and effort to set up so the last thing you want is to fall victim to hackers. Unfortunately, if you haven't also invested in securing your blockchain deployment then that risk is very possible. Various attacks have already been seen on mining software and the tokens in staking wallets make very attractive targets. You may not even realize you have been hacked since savvy hackers are careful to cover their tracks and siphon only a portion of your tokens without you noticing.

Another emerging theme in the crypto community is the potential for sensitive metadata to be exposed through common actions like checking balances, initiating transactions or just receiving block updates. This was recently called out by Ethereum Core Developer Peter Szilagyi. While metadata may seem harmless, it could be used to expose the physical location of a blockchain deployment which is something most would prefer to avoid.

How is this solved today?

A quick check on BitcoinTalk forums reveals sage advice (sometimes learned the hard way) about using VPNs and Firewalls to secure your deployments. Unfortunately, those are often light on details about which VPN or Firewalls to use or how to configure. This leads to more threads about which ports need to be opened for each blockchain and which should be locked down. Blockchain networks can be protected, but it's messy. One misstep could also result in a false sense of security covering a gaping hole.

Secure Mining with the Marconi Protocol

The Marconi Protocol establishes secure connections between all nodes in a network and supports custom filters which can help secure any deployment. With the Marconi Protocol, it's easy to deploy pre-configured filters which serve as a Firewall to block all non-blockchain traffic on your network. That ensures that the only activity happening on your blockchain deployment is the traffic you expect. Any extra ports will be locked down which blocks attackers from accessing your system. With the Marconi Protocol it's also extremely simple to proxy your network traffic to another location to obfuscate your actual location.

Steps for Securing a Network

  1. Firewall Setup

    1. Ensure that the following ports are open on each machine
      • TCP: 24802, 28902, 10004, 23200, 24000-31919, 22
      • UDP: 24000-31919
  2. Node Setup

    1. Follow the setup instructions to install Marconi on each node in your blockchain network.
    2. Make note of the nodeID that is created for each node so you can add that to the network in the following steps.
  3. Network Setup

    1. Create a network using this guide. Reference the nodeID from Step 2 when adding nodes to your new network.
  4. Network Filter Setup

    1. Copy the BTC Filter to the /opt/marconid/bin directory on every node.
    2. Enable the network filter by toggling the packetFiltersEnabled flag in /etc/marconi/marconid/config.yml on each node

Load Balancing

The Problem

As businesses scale today it’s not uncommon for high traffic websites to serve hundreds of thousands, or sometimes millions, of simultaneous requests. To meet this demand organizations spin up new servers to provide bandwidth, redundancy and fault tolerance, but which server should respond when a client makes a request?

The industry standard solution to this challenge is to use load balancers that can listen for client requests and then route them to a pool of servers where the request can be served quickly and reliably. Unfortunately, the industry standard solution has also been to use hardware load balancers which are expensive and inflexible. If more servers are needed or if an environment changes (a common scenario in today’s fast paced environments) then new hardware usually needs to be purchased.

How is this solved today?

Savvy companies today have started shifting to software based load balancers which can address the challenges of elasticity, automation and cost. These new load balancers can be deployed on commodity hardware to reduce costs and built in automation can scale up the number of load balancers as needed. Unfortunately, many of these load balancers still require expensive annual licenses in order to unlock the futures enterprises truly need. Some software based load balancers offered by cloud providers do have lower license / usage fees, but that typically comes at the cost of vendor lock in where you’re required to use their instances for your servers. Many of today's applications that have high demands (e.g. voice & video chat, real time game streaming) also utilize UDP as the communication protocol and some of the top software based load balancers today don't yet support UDP.

Load Balancing with Marconi

With the Marconi Protocol organizations can gain many of the benefits of software based load balancers without the expensive per instance licenses or vendor lockin. Marconi’s open source platform can be deployed on any number of systems as needed without any additional costs and the robust development platform means these load balancers can be easily updated with new configuration or functionality as needed. More importantly, a Marconi based load balancer, leverages the built in connectivity & security features so that the upstream servers for the load balancer can live in a multiple data centers or cloud providers without any additional connectivity headaches. Due to the low level at which Marconi is implemented, almost any protocol (including UDP) is supported.

How to setup a Load Balancer

  1. Firewall Setup

    1. Ensure that the following ports are open on each machine
      • TCP: 24802, 28902, 10004, 23200, 24000-31919, 22
      • UDP: 24000-31919
  2. Node Setup

    1. Follow the setup instructions to install Marconi on each node.
    2. Make note of the nodeID that is created for each node so you can add that to the network in the following steps.
  3. Network Setup

    1. Create a network using this guide. Reference the nodeID from Step 2 when adding nodes to your new network.
  4. Load Balancer Setup

    The remaining commands assume:

    • load balancer is listening on port 27017
    • upstream servers are listening on port 1234
    • upstream servers have IP addresses 10.27.16.11 and 10.27.16.12

    Run the following commands on the load balancer.

    # iptables -A PREROUTING -t nat -p tcp --dport 27017 -j DNAT --to-destination 10.27.16.11:1234 -m statistic --mode nth --every 2 --packet 0
    # iptables -A PREROUTING -t nat -p tcp --dport 27017 -j DNAT --to-destination 10.27.16.12:1234
    
    # sysctl -w net.ipv4.ip_forward=1
    # iptables -t nat -A POSTROUTING -j MASQUERADE
    
  5. Testing Your Load Balancer

    To test your loadbalancer you can create a lightweight server on each of the upstream servers:

    $ while true; do { echo -e "HTTP/1.1 200 OK\r\n$(date)\r\n\r\n<h1>hello world from $(hostname) - TCP</h1>\r\n\r\n$(date)" |  nc -vl 1234; } done
    

    Now, when you send a request to the loadbalancer you’ll receive alternating responses from each of the upstream servers:

    $ echo "hi" | nc <LOAD BALANCER IP> 27017
    
You can’t perform that action at this time.