Giter VIP home page Giter VIP logo

scion-coord's Introduction

⚠️ Discontinued

The functionality of scion-web and scion-coord has been combined into a new web app in the netsec-ethz/scionlab repository. As a consequence, this repository will be archived.

scion-coord

SCIONLab Coordination service

Setup and configuration

Dependencies

Setup go, scion, and scion-coord

Make sure that you have go and python3 installed. Make sure that you have a Go workspace setup, and that ~/.local/bin, and $GOPATH/bin can be found in your $PATH variable. For example:

echo 'export GOPATH="$HOME/go"' >> ~/.profile
echo 'export PATH="$HOME/.local/bin:$GOPATH/bin:$PATH"' >> ~/.profile
source ~/.profile
mkdir -p "$GOPATH"

Then, check out the scionlab branch of netsec-scion into the appropriate directory inside your go workspace:

mkdir -p "$GOPATH/src/github.com/scionproto"
cd "$GOPATH/src/github.com/scionproto"
git clone --recursive -b scionlab [email protected]:netsec-ethz/netsec-scion scion
cd scion

If you don't have a github account, or haven't setup ssh access to it, this command will make git use https instead: git config --global url.https://github.com/.insteadOf [email protected]:

Then, download this repository either by cloning it or by using go get github.com/netsec-ethz/scion-coord.

Go dependencies

The application uses govendor. You need to install govendor via: go get github.com/kardianos/govendor

After this step, you can go to the scion-coord directory ($GOPATH/src/github.com/netsec-ethz/scion-coord) and populate the dependencies in the vendor folder using govendor sync.

Custom configuration

Copy the default configuration file using cp conf/development.conf.default conf/development.conf and adjust the settings to fit your setup. Make sure that you set email.pm_server_token, email.pm_account_token, captcha.site_key, and captcha.secret_key as described below.

Postmark

SCIONLab Coordination service uses Postmark to send emails. You will need an account token and a server token which are obtained by signing up to their service. Set the corresponding fields in the configuration file accordingly.

Captcha

In the configuration file also populate the captcha fields with the keys generated on this site. For a quick start and for testing the keys in the development.conf.default can be used.

Warning: Use these keys only for testing purposes as they circumvent the captcha.

MySQL database

The project needs a working MySQL server instance running locally. Under Ubuntu, you can install MySQL server with the following command:

sudo apt-get install mysql-server

Refer to the conf/development.conf regarding how to set your root password for MySQL server installation. You also need to ensure that there is a database named scion_coord_test.

You can do this by first logging into your MySQL server by mysql -h 127.0.0.1 -u root -p and then executing the following command: CREATE DATABASE scion_coord_test;

Credentials

In order for the configurations to be generated, for each ISD with an Attachment Point the following files must exist (here shown for ISD1):

credentials/ISD1.crt (certificate of one core AS in the ISD)
credentials/ISD1.key (signing key of one core AS in the ISD)
credentials/ISD1.trc (TRC of the ISD)

Certificate authority setup

In order to use OpenVPN inside the generated SCIONLab ASes, it is necessary to set up a certificate authority. We use the tool easy-rsa for this.

Install easy-rsa (version 2.x) using your package manager or download it from the github repository.

Copy the easy-rsa directory to the PACKAGE_DIRECTORY (we assume you are using the default ~/scionLabConfigs). If you installed it via the package manager, you can usually do this by

mkdir -p ~/scionLabConfigs
cp -r /usr/share/easy-rsa ~/scionLabConfigs

Now, copy the default configuration cp conf/easy-rsa_vars.default ~/scionLabConfigs/easy-rsa/vars and adjust the parameters if necessary. You may have to specify the openssl executable (be sure to use openssl 0.9.6, 0.9.8, or 1.0.x). Now you can initialize your certificate authority by issuing (use the default for all prompts):

cd ~/scionLabConfigs/easy-rsa
source vars
./clean-all
./build-ca

In order to setup OpenVPN on the server machine, generate keys using

./build-key-server myservername
./build-dh

Then, you have to transfer files ca.crt, myservername.crt, myservername.key, and dh4096.pem located in the keys directory to the machine running the OpenVPN server. You should delete the server key from this machine.

Run scion-coord

Afterwards, you can run go run main.go from the root folder. Otherwise you can also run the application via:

go build
./scion-coord

Current APIs

The APIs are defined in the main.go file. Additional documentation can be found under Wiki.

scion-coord's People

Contributors

juagargi avatar mlegner avatar ercanucan avatar fr4nk-w avatar xabarass avatar jonghoonkwon avatar matzf avatar silenteh avatar hausheer avatar danieleasoni avatar meldanor avatar pietdevaere avatar simon04 avatar kormat avatar sivaprasadsudhir avatar

Stargazers

Park Hee Chan avatar cucy avatar Raphael Reischuk avatar

Watchers

James Cloos avatar Marc Frei avatar Kamila Součková avatar  avatar Cedric Meury avatar  avatar  avatar  avatar Adrian Perrig avatar  avatar  avatar Claude Hähni avatar  avatar

scion-coord's Issues

[SCIONLab] Ability to update and remove a SCIONLab VM

The current implementation of the SCIONLab VM support allows only adding a new VM to designated SCIONLab ASes. As discussed with @jonghoonkwon and David Hausheer, the next step is to add the ability for SCIONLab users to:

  • Update their VM configurations in case they have a new IP address. This means updating and serving their VM configuration tarball (already in place) on the coordination service and then have the relevant SCIONLab AS update the configuration of the counter part border router .
  • Remove their VMs entirely from the system in case they do not wish to use it anymore. This means adding the necessary front-end and back-end support at the coordination service, and then having the relevant SCIONLab AS remove the counter part border router process from its local configuration.

[SCIONLab] Fix and improve `run.sh` script

There is a bug in run.sh where vagrant is reported to be installed when it is actually missing.
In addition, the script currently only supports mac os and ubuntu. Users of other linux distributions need to manually install vagrant and virtualbox.
It would be nice to automatize this for other distributions as well.

[SCIONLab] Ability to serve the pure gen folder

Currently we serve the whole VM package including the gen folder, vagrant configurations etc.

As discussed with David Hausheer and @perrig, it will be a useful extension for users to be able to download the pure gen folder for their SCION ASes, so that they can run their ASes directly on a dedicated machine, without the use of a VM. This implies that the UI for this feature should not only ask the user to specify his/her public IP address but also the local IP address (which is currently set statically via the Vagrant configuration file) inside their NAT.

[SCIONLab] Create Vagrant image already including SCION and upload to Vagrant repo

The current implementation of our Vagrant configuration downloads a base Ubuntu 16.04 image and then installs and configures SCION at the setup phase.
As discussed with David Hausheer and @jonghoonkwon, it is possible to create an Ubuntu 16.04 image which already includes SCION installation and upload it to Vagrant repository (www.vagrantcloud.com).

This will reduce the required setup time of the VM on the user's side.

[SCIONBox] Add API function to initialize a new SCION box

The function should receive the IP address, MAC address, source IP address from the SCION box via HTTPS. Compare IP address and source IP address to determine if box is behind a NAT. If the box is behind a NAT connect it to a SCIONLabserver similar to how a SCIONLabVM behind a Nat is connected.
Else the function uses IP geolocation and the user credentials to determine the boxes ISD. Then queries its database to find potential neighbors and sends them to the box.
Also we probably want a flag in the message that triggers a simplified call that either chooses neighbors for the box and then sends the gen folder or notifies the system admin to manually configure the box via ssh ( for the geneva box for example )

[SCIONLab] Renaming and refactoring

Some of the terminology used in SCIONLab got more and more confusing over time.
As discussed with @ercanucan and others, we should do some refactoring and rename databases, variables, etc.
I propose the following naming conventions [NewName (OldName): Description]:

  • AttachmentPoint (AP) (SCIONLabAS/SCIONLabServer): SCION ASes to which new ASes can be attached automatically
  • SCIONLabAS (SCIONLabVM): ASes connected to APs that are set up and administered by users
  • SCIONBox: Machines that are automatically managed through scion-coord and connected to APs;
    they can be APs themselves if the connection is good enough

Do you agree with these conventions or suggest different/additional ones?
Another question is what the relationship between SCIONLabASes and SCIONBoxes should be:
Is one a subset of the other or should they be separate concepts?

[SCIONBox] Add database that stores ASes that a new box can connect to.

This database should store all ASes to which a new box can connect to. Along with information like number of neighbors, core, border router IP addresses and ISD. Stored ASes can be SCION boxes or native ASes or SCIONLab servers.
On the same topic ASes will be querying this Database to find out if a new AS wants to connect.

[SCIONLab] Multiple VMs per-user, per-host

As discussed with @perrig, @hausheer and @mlegner, we would like to support multiple VMs per-user, with possibility to run them on the same host.

  • The current implementation of scion-coord (DB, API, UI layers) assumes only one VM per user. This assumption must be relaxed.
  • In order for the user to run multiple VMs on the same host, the Vagrant configuration generation also needs to be updated in terms of forwarded ports, VM names, etc.

Initial boilerplate

I have the skeleton of the scion coordinator web app and REST api.
It contains a set of middleware for dealing with:

  • Authentication
  • Authorization
  • XSRF token to use in combination with angularjs
  • User sessions

In addition the boilerplate allows to have a config file.

API to serve deployed SCION version

As discussed with David (Hausheer), the simplified scion-web UI (netsec-ethz/scion-web#67) should query the currently deployed SCION version from scion-coord.
This way the single machine configuration can be simplified by one more step since the user does not have to choose which version to deploy.

Account registration

Create a REST api for registering users.
The API should take care of gathering:

  • Email
  • Password
  • First and last name
  • Organization name

The API should also make at least a simple validation of those fields.
Finally during the registration process, once a user is successfully registered scion coordinator should generate a key and a secret.
To recap:

  • Gather standard information for the user registration as listed above.
  • Basic validation of the input fields.
  • When successfully registered, generate a key and secret to be used to authenticate the API calls.

[SCIONLab] Additional state "DORMANT" for unused SCIONLab VMs

Currently, border routers in the designated SCIONLab ASes are running indefinitely for any created SCIONLab VM. As discussed with @perrig, for VMs that are not running, these BRs could be switched off and the VM set to an additional state "DORMANT" in order to safe resources.
An email could be sent to the users with instructions to reactivate the VM.

[SCIONLab] Pre-approved invitation-based registration

As discussed with @hausheer, a feature we would like to add is pre-approved, invitation-based registration (with a link the user can click on).

Coordination service should provide a page for the administrator to able to provide a new user's email address and organization. When the "Invite" button is clicked, the new user should receive an email with a link similar to: https://coord.scionproto.net/#/[email protected]&accountid=org

Pre-approved registrations do not need to go through email verification or Captcha.

Testbed topology visualization

A "nice-to-have" feature in SCION Coordination Service would be the ability to visualize the entire topology of the testbed.

Each local scion-web instance would report their topology information (periodically) and scion-coord would combine this information to draw a visualization of the entire topology.

[API] AS id validation

The scion local web interface should send an AS id to the coordinator. This needs to validate the AS id to make sure it is not in use already.
In case it's in use, the coordinator could respond with an error and a list of possible available IDs.

[SCIONLab] Decrease error verbosity

Currently a lot of information is leaked through error messages in order to facilitate debugging.
For the "beta release" of SCIONLab this verbosity should be decreased, possibly at the same time adding a "debug" option to the configuration.

Switch the HTTP API to HTTPS

We currently use Let's Encrypt certificates for Scion Coordination Service.
It's a pre-prod requirement to switch the Go APIs to speak HTTPS instead of HTTP.

[API] Entry point for receiving the signed certificate

Once a core AS accepts the entrance of the newly created account, it needs to sign the certificate uploaded in issue #4
At this point the rest API should also receive information about the core AS:

  • Ip address
  • Port

To recap, the REST API should allow to:

  • Upload the signed certificate.
  • Accept an IP address field.
  • Accept a port field.

Ideally all this is done in once call.

[SCIONLab] Ability to re-send verification email

Currently, scion-coord does not have a mechanism to re-send the verification email.
As discussed with @chaehni and David Hausheer, in case a user loses the verification email before he activates his account or the email delivery fails, it would be useful for the user to be able to re-request the verification email.

[API] Entry point for checking the creation of new accounts

When a new account wants to join scion test-bed network, then the other nodes need to be notified.
Create a simple API which returns some information about this.
TODO: discuss what kind of information the coordinator needs to return.

  • Certificate is definitely one of them.

[SCIONLab] Packaging as-viz into VMs

As discussed with @perrig, downloaded VM configurations should contain SCION AS Visualization tool, so that the users can view the topology of the network.

This feature also requires the following configurations packaged into the VMs:

  • Relevant sciond configuration.
  • Relevant endhost configuration.

Move registration, login and logout to the server side

Handling of the registration and login works fine with angular, however, once the user logs out the XSRF token needs to be regenerated. This seems to cause several issues.
One solution would be to refresh the login page, after a user logged out, however I think it's a better idea to move the whole logic on the server side and keep the angular application only for the administration part. (after logging in)

[API] Entry point for certificate upload

Once the AS id is agreed between the coordinator and the newly created account, then the scion local web interface needs to upload the certificate to the coordinator.

  • Create an API entry point for the upload of the certificate.
  • Simple validation of the certificate by checking that the AS id is present and correspond to the agreed one.

[WEB UI] Display the full network topology

Each AS/Core sends fragment of the network topology.
Re-assemble them together to display the full topology.
Possible ways to display it, I can think of right now:

  • A tree
  • A world map

[SCIONLab] Unified installation script for different platforms

There should be one central script that handles the majority of the SCION setup for different platforms.
This script could then be called from the Vagrantfile, downloaded and executed by the user for a native setup, and be included in the Raspberry Pi and Odroid images.

[SCIONLab] Automatically update topology figure

The topology figure on the front page of the SCIONLab Coordination Service should be automatically updated in regular intervals.
In addition, it should contain names/labels for ISDs and ASes.

[SCIONLab] Connecting to multiple SCIONLab ASes

At the moment, the users of SCIONLab are connected to a fixed SCIONLab AS (1-7 in this case). As discussed with David Hausheer and @jonghoonkwon, the number of allowed SCIONLab ASes should be increased and the users should be able to choose which SCIONLab AS they want to connect to.

[SCIONLab] Integrating SIG into SCIONLab VMs

(short/mid-term) As discussed with @hausheer, one way to make SCIONLab more engaging for the users is to integrate/configure SIG into the SCIONLab VMs. This way the users will be able to send actual traffic through SCIONLab.

[SCIONBox] Add API function to connect a SCION box to the SCION net

This function should receive a list of neighbors from the SCION box. The function then updates the Database, generates the gen folder and sends the gen folder to the SCION box.
The ASes the box connects to, will be querying the Database similar to how the SCIONlabserver queries the database and also update their configuration accordingly.

[SCIONLab] Support for NATted use cases

As discussed with @hausheer, @perrig and @mlegner, one way to provide SCIONLab for NATted cases with changing IP addresses (such as home users) would be to use an OpenVPN-based approach.
In such scenarios, designated SCIONLab ASes would run an instance of OpenVPN server. Each newly created SCIONLab VM (which would connect to such SCIONLabASes) would be generated with configuration to run an OpenVPN client.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.