supernomad / quantum Goto Github PK

quantum needs to support more operating systems than just linux. However it is highly unlikely that quantum will ever support multiple architectures, and will continue to just focus on amd64/x86_64.

Current target OS's are:

• FreeBSD
• OpenBSD
• Darwin
• Solaris (Only If Possible)
• Windows (Only If Possible)

There needs to be a move to using full TLS for quantum vs the current crypto implementation.

Dear Quantum team,
I'm new with quantum, so I have some questions with your quantum solution for classification:

• Do we need any special hardware RNG (Random Number Generator), photon generator,... ?
• What is the different between your quantum software defined with another quantum solution use RNG hardware (ex: http://www.idquantique.com)
• And may I use your quantum software solution for my system in production or your software is just for demo
  Thanks,

There needs to be a way to automatically detect the public ip address of the node, while there will be no way of getting this right every time there needs to be a default catch all.

The idea here would be to generically determine the primary public ip address of the node and use it in the absence of a user supplied public ip.

There is currently a race condition where if the backend data store is still initializing quantum will fail to properly start.

So really there is exactly 0 documentation and this needs to change.

Documenation catagories:

• Code level
  • Really just godoc fully done up
• Application level
  • README and other related documentation about how to initially run/develop quantum
• Implementation level
  • Wiki to help people setup/run quantum in different real world configurations

The idea here is to create a mode of operation that will preform the task of relaying information between different networks.

The relaying would be between either physically or virtually segmented networks. One use case for example would be connecting servers which exist behind a firewall with servers that run either behind a different firewall or in the cloud.

The relay can not handle encryption/decryption, as this would allow for a breach in security.

This will require a fairly large reworking of the data schema in use currently. Up to this point it has been the idea that the networks would be flat, while this will still be supported it needs to support multiple networks.

Securing the different networks is something that will be tackled in a different issue.

So quantum should be able to enable and disable cryptography network wide. The use case here is someone needing a sdn that doesn't need to worry about securing the backend network. There are a myriad of configurations that would not require cryptography to be implemented at the interface level.

This cannot be at the node level due to opening up exploits in the packet pipelines.

Quantum needs to support multiple subnets. The multiple subnets should be able to span any network segment, i.e. the 172.16.0.0/12 network should be able to talk to the 10.0.0.0/8 network. However this needs to be built in a way that will allow locking subnets out of other subnets. Something like the 172.16.0.0/12 can only talk to the 10.8.0.0/16 network.

There will most likely be a new addition in the form of a control binary to manage the subnets and which subnets can communicate.

This needs to be completed before work on #26 can commence.

quantum needs unit testing to ensure versions work as intended. These tests should encompass testing the general functionality of the different modules, but leave integration testing for a different issue.

The target would be anything greater than 95% code coverage.

At the moment the encryption engine is not signing packets, and this is absolutely required to fully enforce security.

The idea would be adding a new step in the incoming/outgoing pipelines that verifies/signs the packet with a new EC key pair. This should be relatively easy to get into the system as we should most definitely rely on the built in ECDSA libraries in the crytpo package.

The keys should be auto generated on startup just like the current keys used for generating the symetric key are generated.

Currently if multiple quantum instances start up at the same time there is a race condition where some of the instances do not initialize properly.

At the moment the entire system relies upon getting the private and public ip's from the end user at start up. There needs to be an additional system that can do configuration on the fly based on the state of the network/cluster.

The idea would be that you can either provide an explicit private and/or public ip address, or allow quantum to determine the addresses for you. The hardest part will inevitably be the public address as NAT is going to throw a wrench into things. However it should be fine as long as there is a way to use both static and auto defined addresses.

I think this needs to be a part of the datastore, as the datastore will be the one handling storage of the addresses and keeping track of state.

So quantum should be able to handle floating fail over ip's over an arbitrary number of hosts. These floating ip's would be assigned to multiple servers, and a single server in that group would claim the ip on startup. In the event that the server which claimed the ip were to lose access to the datastore, the ip would then failover to the next server in the group. However if no servers are responding, the ip should be removed completely, until a healthy server is put back into service.

quantum should support both the legacy v2 and new v3 etcd api as backend datastores. Currently only the legacy v2 api is supported. This is a good first step at supporting multiple backend datastores, and should mean an easy path forward.

Reference for the new api version:
https://godoc.org/github.com/coreos/etcd/clientv3

quantum should be able to be configured with encryption/decryption of packets disabled, at run time. This would mean that any traffic destined for the node in question would be in the clear and any data sent from the node in question would be in the clear.

This would not affect the TLS integrations with the backend, and would be solely for the incoming and outgoing workers to bypass encryption/decryption.

Currently quantum is locked into using etcd as the datastore for the various mappings and configuration. This should be refactored into an interface to allow for multiple backends to be supported.

I think as a starting point both etcd and consul should be fully supported, and investigation into what other datastores would fit the bill needs to be done.

As a rough list of requirements of the datastore:

• Aribitrary values for keys
• TTL on keys
• Watches on keys
• Should provide security to match what quantum is after

One thing that should be at least have hooks baked in is the idea of supporting some kind of plugin like architecture to provide an easy avenue for adding new data stores in the future.

quantum should use all lowercase for all imports.

There is a need to be able to support both an ipv4 and an ipv6 address for those setups that have a mixed bag of support for ipv6. This would enable gradual addoption of a fully public ipv6 setup.

• Needs to be able to support fall back methodologies
  • Perfer ipv6
  • Fall back to ipv4 if available
  • Drop if no communication is possible i.e. a server with only ipv6 talking to a server with only ipv4

This will mean that is possible to dev null yourself to hell so it needs to be very clear its possible.

quantum theoretically has the ability to preform a seamless rolling restart, given that the file descriptors can be passed during a fork-exec operation. According to the go documentation this is possible, so the idea would be to start a new quantum instance but pass in the file descriptors of the TUN and Sockets.

This would effectively allow for the current quantum instance to gracefully terminate, without losing packets.

quantum currently has only one method of configuration which is via the cli.

It needs to be configurable via environment variables and via config files. Each of the methods should have access to the same configuration variables, and should be able to mix and match based on the following hierarchy:

1. Cli
2. Environment Variable
3. Config File
4. Default

Currently the logging in quantum is well abysmal to put it lightly. The entire logging system should be evaluated and an appropriate logging library should be chosen.

We should support at the very least the following levels:

• Debug
• Info
• Error

Potentially a Warn and Verbose level if absolutely necessary.

quantum now has basic DHCP support, and will automatically select and available IP on start up if not configured with a private IP. However these IP's do not persist locally through reboot/restart of the service, and will cause the service to get a new ip on every restart even if the lease time has not expired.

So persistent DHCP leases need to be implemented, this should be a simple matter of saving state to disk somewhere. The state needs to be validated on lease expiration, and never overwrite existing keys if state is expired.

Right now if you run quantum with multiple servers using a combination of static and dhcp ip allocations, there is a chance at hitting a collision where private ip's can be assumed by a different server.

quantum is going to need a slew of integration tests to ensure proper functionality.

These should include:

• Testing the different backends
  • Test watches
  • Test tls
  • Test auth
• Testing sending packets between multiple nodes
  • These should include trying to send packets between networks
  • These should also include benchmarking performance

Libkv is unfortunately proven to be a burden and resource hog when it compares to the pure etcd approach that was originally in place. The change should be reverted so that the complexity can be kept at a minimum.

This will mean sacrificing the capability to run with consul, however a pure consul approach would probably be as beneficial as the etcd approach will be. So that can be considered down the road.

When a quantum instance is configured to forward all network traffic, there is no way for quantum to recreate the forward setup after a soft reload. There is an added issue that after a reload subsequent reloads/shutdowns fail due to an invalid pointer because there is no default gateway to put back into place.

To be clear the inital reload properly removes the forwarding setup but does not recreate it.