Create a policy page and move instructions to join the infra #125

mkowalski · 2019-11-21T15:36:46Z

Closes: #111

This change is

content/join/policy.md

content/join/instructions.md

content/join/policy.md

AnotherKamila · 2019-12-04T09:56:56Z

content/join/policy.md

+3. Allow the SCIONLab management institution to install, remove and update SCIONLab related software as needed for the operation and maintenance of the network.
+4. Work with the SCIONLab management institution to solve any firewall and tunneling issues that may arise during the installation, configuration and operation of the SCIONLab node(s).
+5. Provide the name, email and telephone information of an easily and quickly reachable site-specific operator who will be the main contact whenever issues arise with the local SCIONLab node(s). A backup operator, while not required, is highly encouraged. Operator email addresses must belong to the institution. All local operators will be required to join and regularly monitor an SCIONLab community mailing list and are required to respond to requests from the testbed management institution in a reasonable time, but no more than 3 working days.
+6. Ensure that the machine has limited logins beyond the SCIONLab account. A local operator account is highly encouraged, but general user accounts should not be present on the SCIONLab node. In addition, only SCIONLab-related software should be allowed to run on the machine.


Is this actually true? Don't we want to allow e.g. active researchers that do stuff with SCIONLab to have access to the machines? (Maybe not, because researchers mess things up :D but if not, then who exactly is the target group for joining the infra?)

This is very true. If they want to play with the machine, they should be using user AS. I do not trust any of this dudes to do anything inside this machine and not breaking stuff

Okay, but:

we say "[blablabla] you are committed to do research with SCION, and using user ASes is not enough for your plans" in instructions.md

we say "Connecting to the testbed for the sake of being connected is a violation of the current policies" in policy.md

So that sounds to me like we want people to join the infra when they want to do fancy research with it.

And then we say "limited logins beyond the SCIONLab account" here, so that they cannot do fancy research with it :D

So, it seems to me that these three things together strongly limit who is supposed to be joining the infra and why. The only use case that I can come up with while satisfying all three is just something like "we really really want a local attachment point". Is this actually the only use case? If no, please tell me about another one :D And if yes, should we just say that explicitly at the beginning of instructions.md?

Okay, let me give you a specific example. We have a SCIONLab node somewhere in Austria (I believe TU Vienna), where some "Charlie dude" logs into the machine and changes configuration of the SCION services to something super dumb, making the services fail hard during the start-up. As this is not transparent for the rest of the network, I do not want him to be allowed to misconfigure stuff. By this I mean the configuration of the infrastructure should be stable and deterministic and someone ssh-ing and modifying random files contradicts both these points.

Let me give you a second example. We used to have a node in Israel which was not used by anyone for an unknown amount of time. Once this node has died (i.e. went no-contact without anybody informing us) it took these guys more than 3 months to reply to Juan's email. I need a mechanism to enforce a strong reaction in these cases as I do not want SCIONLab to become a graveyard of machines which used to work once and nothing more.

AnotherKamila · 2019-12-04T09:57:31Z

content/join/policy.md

+5. Provide the name, email and telephone information of an easily and quickly reachable site-specific operator who will be the main contact whenever issues arise with the local SCIONLab node(s). A backup operator, while not required, is highly encouraged. Operator email addresses must belong to the institution. All local operators will be required to join and regularly monitor an SCIONLab community mailing list and are required to respond to requests from the testbed management institution in a reasonable time, but no more than 3 working days.
+6. Ensure that the machine has limited logins beyond the SCIONLab account. A local operator account is highly encouraged, but general user accounts should not be present on the SCIONLab node. In addition, only SCIONLab-related software should be allowed to run on the machine.
+7. The machine may be a dedicated physical box or a virtual machine with a publicly routable IP address (i.e., should not be behind a NAT). The local operators should ensure that if the machine has usage limits or other restrictions (for example VMs on cloud services), those will not interfere with proper testbed operation.
+8. In case more than one machine is being provided by the institution, it is allowed if only one of them has a publicly routable IP address whereas the others use private static IP.


This is to cover the following use case

multi-host AS

border router has a public static IP for the uplink connectivity

services inside AS talk with each other using static private IPs (because public are not needed as long as inside-AS connectivity works)

what about having having multiple border routers for uplink?

This is a valid scenario, we should then write something closer to "machines hosting border routers must have a public static IPv4 address"

AnotherKamila · 2019-12-04T09:58:45Z

content/join/policy.md

+11. Suggested Location: SCIONLab node should reside in a machine room in a rack.
+12. Suggested Network Connectivity: There is no minimum bandwidth requirement for SCIONLab nodes; however, higher network speeds are both recommended and desirable.
+13. Participating institutions may disconnect from the testbed upon giving appropriate (at least 24 hours) notice to the SCIONLab testbed management institution. The same policy applies if the participating institution wishes to turn off the machine for maintenance and/or hardware upgrades. Early notification will allow the testbed management institution to take any actions necessary to prevent unnecessary disruption of service to the testbed.
+14. We strongly discourage and will not accept requests to join the SCIONLab testbed if there is no intention to use it for productive research. Connecting to the testbed for the sake of being connected is a violation of the current policies.


(does this mean that like half of our nodes are in violation of the current policies? :D)

Just to make it clear, this does not mean we are removing half of the nodes from day 1. This only means once we have a node which obviously misbehaves and no one reacts in a reasonable amount of time, we have a CYA to throw at them and enforce an action (this being either cooperation or removal).

AnotherKamila · 2019-12-04T13:22:20Z

General issue: it should be explicitly mentioned somewhere at the beginning of instructions.md that if a user AS is enough, you can do that. Just to avoid people getting confused and thinking they need to do this in order to get their own AS and thinking "you need root to let me have an AS? f*** off from my network"

mkowalski · 2019-12-04T18:10:16Z

General issue: it should be explicitly mentioned somewhere at the beginning of instructions.md that if a user AS is enough, you can do that.

I believe this is we are trying to implicitly push, but maybe we should emphasize it even more.

Also you know my view... I still stand strong on the opinion that whoever claims SCIONLab is ready to run in a federated-responsability model has not seen a life outside of his office. Currently people outside of our office (excluding Anapaya) do not have a knowledge how to run SCION infrastructure, therefore we have 3 options

we go around and start training them
we manage stuff for them
we let them do whatever they want

While (1) is something we are not obviously doing at the moment, I believe a mixed model of (2) and (3) is the way to go right now. Mixed meaning SCIONLab Infrastructure strictly follows (2) and SCIONLab User ASes follow (3).

mkowalski

Reviewable status: 0 of 3 files reviewed, 8 unresolved discussions (waiting on @AnotherKamila and @FR4NK-W)

content/join/policy.md, line 11 at r1 (raw file):