search

netsec-ethz / scion-tutorials

Website providing step-by-step instructions on participating in the SCIONLab network.
https://docs.scionlab.org
4 stars 26 forks source link

Update requirements for INFRA nodes #111

Open mkowalski opened 4 years ago

mkowalski commented 4 years ago

Background

As an operator I want to clearly define a minimum set of requirements to be met before a node can become part of SCIONLab as infrastructure node.

State

The current version of scion-tutorials/content/join_infrastructure.md is highly outdated mainly (but not only) in parts about operating system and firewall rules.

[A] There also statements which we don't want to have, like you can start as small as dedicating only a simple commodity PC. In this case user should be running an user AS as this is highly probable a commodity PC will be an old&cheap machine under someone's desk without any operational support at all.

[B] Currently we require minimum of 4 GB of RAM. This is not enough in many cases and causes us to run at the edge what also increases operational costs in case strange things happen. Nowadays a reasonable requirement should be 8 GB of ram and at least 4 vCPUs.

[C] A model operating system for the infrastructure node is currently Ubuntu 18.04.

[D] border router node(s) must have a public static IP should be extended to a requirement where all the nodes have static IPs. Otherwise that would mean for intra-AS communication we need to deal with dynamic IPs what sounds crazy.

[E] The sentence it may be enough if a firewall allows return traffic to the same port sounds very vague. For people dealing with firewall configurations it's more than enough to be told something like "incoming traffic from X to Y over port Z"

[F] Address ranges for management SSH traffic are very incorrect.

[G] The last option in we can also operate the connections over a tunnel, e.g. OpenVPN, Wireguard or SSH tunnels should be removed. I cannot imagine operating anything more than "debug & very temporary test" via SSH tunnel as this thing is not properly deployable, monitorable nor operatable.

Further improvements

As a further enhancement I want to provide a "hardened configuration" in case there is a business requirement to run in a harsh/strict environment, given the value is higher than investment needed.

mkowalski commented 4 years ago

I guess some cooperation/assistance via @AnotherKamila would be helpful here

AnotherKamila commented 4 years ago

@mkowalski Ack, added to the end of my queue ;-)

mkowalski commented 4 years ago

A somehow relevant reference could be https://named-data.net/ndn-testbed/policies-connecting-nodes-ndn-testbed