Notice

This documentation is still in progress. Come help here!

Network

This section documents the network and its nodes.

Supernode 1

image

Supernode 1 is located on top of 200 Woolner Ave, Toronto, alongside Cisco-deployed infrastructure belonging to the City of Toronto.

Network

The supernode consists of 2 antennas and a router. The router is connected to the Cisco switch which is connected to the Bell 2000 modem that offers internet access for use as a gateway path.

The router acts as a Babel routing device. The antennas are configured in bridge mode.

image

Hardware

Antenna 1

Antenna 1 is a Ubiquiti LAP-120 mounted on the west arm of the building, on the south side of the roof, colocated with Cisco on their mounts. The antenna is facing south.

image

Antenna 2

Antenna 2 is a Ubiquiti LAP-120 mounted on the south arm of the building, on the east side of the roof, colocated with Cisco on their mounts. The antenna is facing east.

image

Antenna 3 and 4

Antenna 3 and 4 are Ubiquiti LAP-120 devices mounted on the north-east arm of the building. Antenna 3 is facing north-east and antenna 4 is facing north.

image

Router 1

Router 1 is a Ubiquiti EdgeRouter X-SFP mounted inside the Cisco cabinet in the ballast room. It is connected to the exit node over a L2TP tunnel using UDP.

Router is configured with a static IP and only routes to the exit node and a secondary VPS server. The secondary VPS is used to provide an OpenVPN tunnel for secure remote management of the device.

image

Physical Environment

The roof is accessible through ceiling hatches on the top floor of the building.

image

The router is installed in a black metal cabinet, located on the back wall of the ballast tank room on the roof. This room is accessible only from the roof. The entrance is on the east wall of the elevator hut. The doors are shorter than normal.

Network cables are run through a hole in the east wall.

image image

Neighbourhood Testing

Testing was done at several points that had line-of-sight to the antenna. The antenna was hand-held, not tuned precisely. Results are for reference only, and do not necessarily represent what a permanent deployment could attain at that distance.

PointDistance (m)PingSpeed RX/TX (Mbps)Signal (dBm)
a2004.5786/194-64
b2002.8680/194-60
c2375.8250/178-58
d2705.27103/149-50
e (1)3965.1183/172-58
f25204.578.68/1.6-81
f (2)25204.5764.58/40.79-74
g266082/123-62
g (3)2660118/44-66

(1) Used both Nanostation AC (Loco5AC) and LiteBeam AC (LBE‑5AC‑23). Both performed the same.
(2) Second attempt done after correcting issue with sn1a2.
(3) Used Nanostation AC (Loco5AC) but could not adjust elevation.

Additional Notes

EdgeRouter X-SFP does not accelerate traffic over tunnels. Due to this, speeds are currently limited to around 400Mbps to exit node.

Exit Node Configuration

Note: This is an advanced topic. If you are not familiar with the concepts in this document, please familiarize yourself with them first before proceeding.

Instructions are for installing an exit node on the Debian 10 operating system.

Babeld Installation

Install the latest version of babeld on the node. The latest version can be found currently at https://repo.tomesh.net/repos/apt/debian/pool/main/b/babeld/

Redistribute default gateway

Redistribute the default gateway to network, and prevent other exit node announcements from being accepted.

Create or append to the /etc/babeld.conf file

redistribute ip ::/0 le 64 metric 256
redistribute ip 0.0.0.0/0 le 24 metric 256
in ip 0.0.0.0/0 le 0 deny
in ip ::/0 le 0 deny

Enable NAT

Create /etc/rc.local and chmod +x it

Add the following content to the file

#!/bin/bash
ip6tables -t nat -F POSTROUTING
iptables -t nat -F POSTROUTING
ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
exit 0

L2TP tunnels

Layer 2 tunneling protocol is used to allow gateways to connect over the internet to the exit node.

Server side scripts that support DDNS can be found in the toronto-community-network repository.

Babel

Babel is a loop-avoiding distance-vector routing protocol. It does link cost estimation and redistribution of routes from other routing protocols.

The network uses the reference implementation of Babel called babeld. Updated packages for Debian can be found at the Toronto Mesh Debian repository. These packages are compiled from source and packaged using scripts in the mesh-packages GitHub repository.

The package for the EdgeRouter X/SFP with UI support is managed by Toronto Mesh and can be found at https://github.com/tomeshnet/RouterX-Babeld-Package.

Prototype babeld configuration can be generated at http://node2.e-mesh.net/CONF/ for both OpenWRT and Linux.

When is Babel needed?

Babel is only required when your node routes IPs or a subnet that was not provided by a remote node.

Babeld console

Depending what port the service started on (local-port or -G options) you can access babeld's console using on of the following (assuming 999 is the port).

  • nc :: 999
  • telnet :: 999

Note that some versions of nc do not support IPv6 so that command will not work.

Dump Command

The command dump in the console will list all the currently known data points of babeld.

add interface <INT> up true ipv6 <IPv6> ipv4 <IPv4>

Indicates that the interfaces <INT> will be used to find other babeld nodes. <IPv6> and <IPv4> are required for routing traffic through the nodes. If one is missing check your interface configuration.

add interface <INT> up false
Indicates the interfaces is assigned to babeld, but are currently not functional (cable not plugged in, or simply down)/

add neighbour f3ecb0 address <IPv6> if <INT> reach ffff ureach 0000 rxcost 96 txcost 96 cost

Indicates nodes found directly connected to babeld. <IPv6> is the local link IP found on the remote node, <INT> is the interface this link was found on. The combination of the two (<IPv6>%<INT>) is used to access the link.

add xroute...metric 256
Indicates the routes babeld is announcing from its routing table. metric 256 is the cost that it is announced as.

add route ...
Indicates routes that babeld has learned about in the network. installed yes or installed no indicates if this route is actively being used by being installed in the node's route table. Make note of metric numbers as they inform if the link will be used or not.

Hardware

This section documents the hardware used and tested for the network.

Hardware Benchmark

Lab setup

Device Device being tested

Endpoint1, Endpoint2 Devices not limited by CPU or network.

image

Instructions below are non-persistent. When device is restarted changes will be removed. wireguard package must be installed.

Device Lab Configuration

Configure interfaces

Configure the IP addresses on each interface

eth0 Interface on device connected to Endpoint 1

eth1 Interface on device connected to Endpoint 2

If the device has only one port, see Appendix A - Single Port Router to split the single port into two VLANs.

ifconfig eth0 NETMASK 255.255.255.0
ifconfig eth0 192.168.1.1 up

ifconfig eth1 NETMASK 255.255.255.0
ifconfig eth1 192.168.2.1 up

Note: You can add other IP addresses to an interface by using the ethx:x notation such as eth0:1. This can be used to add your home IP address alongside the lab's IP address and share the same switch

For example ifconfig eth0:1 192.168.10.1

Enable Routing

Most Linux distributions have routing disable. Enable it.

echo 1 > /proc/sys/net/ipv4/ip_forward

WireGuard

Configure a WireGuard server. Create a configuration file wg0.conf containing a private/public key.

NOTE: Do not use these keys in production!

cat <<"EOF"> wg0.conf
[Interface]
PrivateKey = 4LMdS6DPRe5gHcmMWYhZqlM9PzFTEeDz0kz0YIMCPm0=
ListenPort = 1000

[Peer]
PublicKey = //C9KkNgCgT/0+bIb6YMS558xNx6wJOwAuGbqO8CGlI=
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
EOF

Bring up the wg0 interface using above configuration

ifconfig wg0 down
ip link del dev wg0
ip link add dev wg0 type wireguard
wg setconf wg0 wg0.conf
ip addr add 10.254.254.1/24 dev wg0
ifconfig wg0 up

Endpoint1 Lab Configuration

Configure interfaces

Configure the IP addresses the interface. Make the default route the Device.

eth0 Interface on device connected to Device

ifconfig eth0 NETMASK 255.255.255.0
ifconfig eth0 192.168.1.2 up
ip route add 0.0.0.0/0 via 192.168.1.1

WireGuard

Configure a WireGuard client. Create a configuration file wg0.conf containing a private/public key.

NOTE: Do not use these keys in production!

cat <<"EOF"> wg0.conf
[Interface]
PrivateKey = cFP6gBOZrvqlt/XkdT7Cp6HOLuNMYa6yVNcCR+e9IEw=
ListenPort = 1000

[Peer]
PublicKey = 1510YjIH8EfQtJ2zxEEUb5+1B4HqmIv86pwpkJwNOW4=
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = 192.168.1.2:1000
EOF

Bring up the wg0 interface using above configuration.

ifconfig wg0 down
ip link del dev wg0
ip link add dev wg0 type wireguard
wg setconf wg0 wg0.conf
ip addr add 10.254.254.2/24 dev wg0
ifconfig wg0 up

Endpoint2 Lab Configuration

Configure interfaces

Configure the IP addresses the interface. Make the default route the Device.

eth0 Interface on device connected to Device

ifconfig eth0 NETMASK 255.255.255.0
ifconfig eth0 192.168.1.2 up
ip route add 0.0.0.0/0 via 192.168.2.1

Testing

iperf3 package must be installed. During iperf3 tests there are several things to remember:

  • iperf3, when run on device with low CPU resources, can consume CPU power to generate packets. Speed when transmitting will be slower than when receiving since the CPU will be taxed more

    • using the --repeating-payload flag can reduce the stress placed on the CPU by not generating random data to transmit
  • CPU load can be seen by using the top command during the test

  • Watching /proc/interrupts can also show where CPU cycles are being spent

  • Some devices have hardware offloading that can increase performance when routing through the device

Interface speed

This will test the interface speed between the Device and Endpoint1.

On Endpoint1:

iperf3 -s

On Device:

  • Test Forward speed iperf3 -c 192.168.1.2

  • Test Reverse speed iperf3 -c 192.168.1.2 -R

WireGuard to WireGuard

This will test the interface speed over WireGuard.

On Endpoint1:

iperf3 -s

On Device:

  • Test Forward speed iperf3 -c 10.254.254.2

  • Test Reverse speed iperf3 -c 10.254.254.2 -R

Endpoint2 through Device to Endpoint1

This test will show how well the Device can route packets between subnets.

On Endpoint1:

iperf3 -s

On Endpoint12:

  • Test Forward speed iperf3 -c 192.168.1.2

  • Test Reverse speed iperf3 -c 192.168.1.2 -R

Endpoint2 through Device over WG to Endpoint1

This test will show how well the Device can route packets between subnets while encrypting traffic over the wg0 interface.

An additional route needs to be added on Endpoint1 to send all packets back over wg0 when doing reverse test.

On Endpoint1:

ip route add 192.168.2.0/24 dev wg0 iperf3 -s

On Endpoint2:

  • Test Forward speed iperf3 -c 10.254.254.2

  • Test Reverse speed iperf3 -c 10.254.254.2 -R

On Endpoint1 (once completed test): ip route delete 192.168.2.0/24 dev wg0

Appendix A - Single Port Router

If a device only has one port, routing can be accomplished using 2 VLANs and a switch. You may required to use modprobe 8021q to enable VLAN support.

Device VLAN Configuration

Split the interface into two VLANs creating 2 interfaces called eth0.10 and eth0.11.

apt-get install vlan
vconfig add eth0 10
vconfig add eth0 11

Switch Configuration

When a managed switch is used, port connected to the device should be configured as a trunk or general mode and VLAN 10 and 11 set as tagged. Two other ports on the switch should then be configured as access to VLAN 10 and VLAN 11 respectively. In this setup the VLAN is transparent to Endpoint 1 and Endpoint 2.

When an unmanaged switch is used, Endpoint 1 and Endpoint 2 must be configured to use access the VLAN directly.

Endpoint 1 VLAN Configuration

apt-get install vlan
vconfig add eth0 10

Endpoint 2 VLAN Configuration

apt-get install vlan
vconfig add eth0 11

Benchmark Results

Definitions

D2E Device to Endpoint - Device connected to endpoint and iperf3 between the two.

E2E Endpoint to Endpoint - Device connected to two endpoints on different subnets. iperf3 between two endpoints through device.

WG D2E Device to Endpoint over WG - Device connected to endpoint with wg tunnel and iperf3 over wg.

WG E2E Endpoint to Endpoint over WG - Device connected to two endpoints on different subnets. wg between device and one endpoint. iperf3 between two endpoints through device over WG

L2TP D2E Device to Endpoint over L2TP - Device connected to endpoint with L2TP tunnel and iperf3 over L2TP.

L2TP E2E Endpoint to Endpoint over L2TP - Device connected to two endpoints on different subnets. L2TP between device and one endpoint. iperf3 between two endpoints through device over L2TP.

Results

DevicesD2EE2EWG D2EWG E2EL2TP D2EL2TP E2E
AtomicPi923837895665767/863798/705
EdgerouteX533/356750/510
EdgerouteX FastPath569/388913/927217/180180/211312/188320/290
EspressoBin931335/403213/335
OmniTik POE900
PC Engines apu2c4936645
Raspberry Pi 4B950770
WRT1900ACV1920879350/450280/338

Operations

This section documents the operational aspects of the project.

Working Groups

We use GitHub Teams to manage membership of working groups and GitHub Projects to track task status on a public project board. These are our current working groups.

Communications and Community Engagement

Connect with people living and working in the areas served by the network(s), inform people regarding intentions and activities of the community network and engage them in dialogue with a view to mutual learning and collaboration in advancing the value of the network and related opportunities in the community.

Spaces
MeetingsSunday 3 PM ET weekly (calendar iCal time poll)
Group Emailcommunications@tomesh.net
Chat#communications:tomesh.net
Taskscommunications label
Membershipcommunications-and-community-engagement team

Network Planning, Design and Operations

Plan, design, implement and maintain a well-functioning community network.

Spaces
MeetingsThursday 5 PM ET weekly (calendar iCal time poll)
Group Emailnetwork@tomesh.net
Chat#network:tomesh.net
Tasksnetwork label
Membershipnetwork-planning-design-and-operations) team

Organizational and Program Governance

Develop administrative processes ensuring Toronto Mesh meets their commitments. Attend to assets and resources. Assist in integrating and synthesizing priorities, plans and schedules across different disciplines and activities to realize the mission of Toronto Mesh and the Toronto Community Network. Formalize relationships and agreements with and within the community network.

Spaces
MeetingsMonday 6 PM ET weekly (calendar iCal time poll)
Group Emailgovernance@tomesh.net
Chat#governance:tomesh.net
Tasksgovernance label
Membershiporganizational-and-program-governance team

Project Operations

Assist in organizing and removing barriers to the completion of work - including projects involving production of a funding application, design and deployment of network equipment, convening of meetings and workshops, etc.

Spaces
MeetingsSaturday 12 PM ET biweekly (calendar iCal time poll)
Group Emailoperations@tomesh.net
Chat#operations:tomesh.net
Tasksoperations label
Membershipproject-operations team

Get Involved

If you would like to join a working group and contribute to the Toronto Community Network, please email hello@tomesh.net to introduce yourself and indicate how you may like to participate.

In order to do our best work together we have a Code of Conduct.

Learning Group

Toronto Community Network has established a learning group for us to develop deeper understanding about projects related to our community network. This group meets regularly with the Organizational and Program Governance Working Group and you can find the meeting schedule on our calendar.

Reading List

Please use the notepad associated with each reading to indicate your name once you have completed the reading, and to put your reflections and questions anonymously, so we can decide which readings are ready to be discussed when we meet.

  1. Development and management of collective network and cloud computing infrastructures (notepad, added 2020-08-29)

  2. Community Networks Adapt to New Realities Under COVID: A DWeb Meetup Recap: Zenzeleni Networks (notepad, added 2020-08-29)

  3. Constellations of Trust and Distrust in Internet Governance (notepad, added 2020-08-29)

  4. The Tragedy of the Commons: How Elinor Ostrom Solved One of Life’s Greatest Dilemmas (notepad, added 2020-09-09)

  5. Toronto Mesh Mission (added 2020-09-09)

Please add interesting articles here for the group to triage as future readings.

Legal

Toronto Mesh is a community organization established in 2016, stewarded by a group of individual contributors and supported by many value-aligned organizations. It is not an independent legal entity.

The Toronto Community Network is a project led by the Toronto Mesh community, and adopts a multi-stakeholder model to its project governance. Since neither Toronto Mesh or the Toronto Community Network has its own independent legal entity or bank accounts, it relies on trustees to provide fiscal administration capacity.

It is necessary for Toronto Mesh or the Toronto Community Network to engage into contractual agreements to work with many institutional collaborators. Depending on the nature of the collaboration, our Organizational and Program Governance Working Group will designate appropriate signatories to sign the agreement on behalf of Toronto Mesh or the Toronto Community Network on a case-by-case basis.

We understand that some organizations can only work with legally registered entities. If a contract must be made with a legal entity, we suggest a contract covering a specific project scope be made with one of our institutional collaborators. This way, you can indirectly work with the Toronto Community Network through this institutional collaborator. It is important to note that this contract will not bind Toronto Mesh or the Toronto Community Network as a whole, as collaborators do not individually represent the entire multi-stakeholder project.

Deciding Appropriate Signatories

TBD

Collaborators and Supporters

Licenses

Unless otherwise specified, Toronto Mesh code is licensed under GNU General Public License v3.0, content and documentation is licensed under Creative Commons Attribution-ShareAlike International 4.0 (CC BY-SA 4.0).

Finances

The purpose of this document is to describe the financial status and processes of the Toronto Community Network.

Introduction

The Toronto Community Network is a community project that current does not have its own independent legal entity or bank accounts, and relies on trustees to provide fiscal administration capacity. Aside from out-of-pocket spending from some of our members, our current financing comes from one single grant from the Internet Society administering through Free Geek Toronto.

Internet Society Grant for Supernodes (2020)

Internet Society was involved in discussions since ideation phases of the Toronto Community Network, and that is reflected in our Proposal to Establish a Toronto Community Network. This eventually led to a grant focused on deployment of high-capacity supernodes, which will establish an initial backbone from which to grow and sustain the Toronto Community Network. The initial supernodes span several major neighborhoods across the City of Toronto, selected and scheduled according to opportunities presented by the City of Toronto and our other collaborators through the Digital Canopy project.

The grant totals CAD 13,525 with the following budget:

  • $10,428.00 for hardware, covering 4 supernode deployments
  • $1,744.50 for operational expenses, including data centre colocation and internet transit
  • $1,352.00 for grant administration, a 10% fee retained by our fiscal host Free Geek Toronto

The funds are payable to Free Geek Toronto in two installments, CAD 7,000 followed by CAD 6,525 upon completion of the milestone where 2 supernodes have been deployed. Toronto Mesh estimated a contribution of 1630 member hours of volunteer labour to the project.

Toronto Mesh and Free Geek Toronto are expected to deliver 3 reports by the following dates:

  • 1st report: September 30, 2020
  • 2nd report: November 15, 2020
  • Final report: January 31, 2020 (summarizing all the work done until December 31, 2020)

Four core members of Toronto Mesh, who will serve as Administrators for this grant (explained below), have signed a Memorandum of Understanding (MoU) with Free Geek Toronto to formalize the fiscal hosting relationship. The full Internet Society Partnership Agreement and MoU are archived on our trusted drive, accessible only to core members due to confidentiality requirements from our partners.

Administration

The first of two installments in the amount of CAD 7,000 is paid to Free Geek Toronto in September of 2020, and the balance of CAD 6,300 (after 10% of administrative fees) is to be distributed for the project according to the budget set out in the grant proposal. We have two-levels of approvals for fund allocations:

  1. Four members of Toronto Mesh involved in the grant application are selected as Administrators, and will approve allocations according to whether an expense fits with the spirit of the grant objectives and its proposed budget.

  2. Free Geek Toronto will approve allocations according to the MoU, and they reserve the right to reject allocations that may put them in a position of legal liability due to violation of grant terms.

Expenses generally require pre-approval and receipt copies, archive and tracked in a spreadsheet on our trusted drive.

In the course of administering the grant, Administrators may draft request for proposals (RFPs) or delegate budgets to working groups to allocate as they deem necessary. For example, the Administrators may allocate a budget for training and request for member applications, or delegate a small budget for the Communications and Community Engagement working group to spend on an event as they see fit.

Hardware purchase makes up the bulk of the Internet Society grant budget. The Network Planning, Design and Operations working group will be responsible for making hardware procurement proposals using the following template, submitted as a pull request to operations/hardware-budgets:

# YYYY-MM-DD Hardware Budget for Toronto Community Network

## Purpose

_What is the hardware for? If this is related to a particular deployment and require approval by a specific date, please mention it here._

## Hardware List

_A list of all hardware items and the prices from specific vendors we plan to order from._

| Item   | Vendor   | Price | Currency | Quantity |
|:-------|:---------|------:|---------:|---------:|
| Item 1 | Vendor 1 |  0.00 |      CAD |        1 |
| Item 2 | Vendor 2 |  0.00 |      USD |        1 |

## Budget Requested

_The Administrators acknowledge that final reimbursement amounts may differ due to unforeseen costs like duties and exchange rates. This should be a best-effort estimate in Canadian Dollars._

| Budget    | Estimate (CAD) |
|:----------|---------------:|
| Hardware  |           0.00 |
| Shipping  |           0.00 |
| Duties    |           0.00 |
| Taxes     |           0.00 |
| **Total** |           0.00 |

## Sign-off

_The sign-off should include at least one experienced member in the Network working group._

Members of Network Planning, Design and Operations:
- Member 1
- Member 2

Grant Administrators:
- Administrator 1
- Administrator 2
- Administrator 3
- Administrator 4

For budget allocations above CAD 1,000, approval by 3 of 4 Administrators are needed. For amounts below that, only 2 of 4 approvals are necessary. The four Toronto Mesh Administrators are: @darkdrgn2k, @TimTor, @Shrinks99, and @benhylau.

Data

Toronto Community Network operates on principles of transparency, so most of our work is conducted in public digital spaces. The exception to this rule is when managing with personal information and sensitive information of our supporters and collaborators. This document describes our policy is finding the balance between working openly and restrictive access to certain information.

Document Management

We store our documents on two main platforms:

  1. Our Toronto Mesh GitHub hosts our main organizing repository in addition other repositories for more specific content, like data about our community network nodes.
  2. Our self-hosted Nextcloud drive contains two folders with different access levels:
    • tomeshnet stores semi-public information. Any Toronto Mesh member gets full access.
    • tomeshnet-trusted stores sensitive information, such as contact lists containing personal information and collaborator contracts that are explicitly asked to be kept private. Only active members with more than one year of contribution in our working groups have access to this folder, and access shall be revoked when the member is no longer actively involved with the project. In special cases, access may be allowed to specific members with less history as contributor on an as-needed basis, by approval of the Organizational and Program Governance Working Group.

Communication Policy

In general, we copy email and other communication to a working group address, for reasons of transparency and information redundancy. However, there are times when we seek to contain communication to a small group (for example, engaging new prospective collaborators, handling Code of Conduct violations). In these instances, we seek to keep groups to at least 3 members--one as lead, two copied, and have these roles listed on our contact sheet. Here is our communication policy in order of preference:

  1. Copied to appropriate working group.
  2. Copied to two others.
  3. Temporarily individual, but move to high redundancy as soon as possible.

Meeting Recording

In general, we do not record our meetings, but for workshops/interviews we have three options in order of preference:

  1. Public recorded session with unrecorded discussion in the end (for example, publish on "YouTube").
  2. Private recorded session with unrecorded discussion in the end (for example, archive to our member Nextcloud).
  3. Unrecorded session.

This is a choice of the facilitator/presenter of the session. Where possible, we will publish to a platform with closed captioning for accessibility.

In general, we have recorded sessions at our recorded BigBlueButton room, where a disclaimer is presented when someone enters the room.

Network Data

TBD

Managing Secrets

The purpose of this document is to provide information to contributors on how to store and view the Toronto Community Network's "secrets", such as passwords, keys, credentials, and other information kept private for security reasons.

Introduction

The Toronto Community Network uses Bitwarden to share and manage secrets across the organization. Bitwarden is a free and open-source password management service that stores sensitive information (such as website credentials) in an encrypted vault.

Bitwarden supports the following clients:

  • Desktop (Linux/macOS/Windows)
  • Web Browser (Chrome/Safari/Firefox/Vivaldi/Opera/Brave/Edge/Tor Browser)
  • Mobile (Android/iPhone)
  • Command Line (via NPM)

For more information about supported clients, see Bitwarden's download options.

Accessing Secrets

The Toronto Community Network is using the self-hosted version of Bitwarden, and can be accessed at https://pass.tomesh.net.

For secrets to be shared, they must exist within the Toronto Community Network organization.

When using the Bitwarden applications, please make sure to change the Server URL in the Bitwarden settings to the https://pass.tomesh.net.

Obtaining Access

Obtaining access to Bitwarden is a 4-step process.

  1. Send an email to operations@tomesh.net with the following information:

    • Your Name
    • GitHub Handle
    • Detailed description of your use case or requirement.
  2. A member of our Project Operations team will invite you to Bitwarden.

    • Bitwarden will send you an email from tomeshnet@gmail.com
    • Please make sure to whitelist the email address.
  3. Use the link in the invitation to create an account.

  4. After registration, Bitwarden requires us to confirm your account. Upon confirmation, you will have access to the organization.

We recommend that you setup two-factor authentication on your account to increase the security of your account.

Access Control

When storing credentials, you must store them within the Toronto Community Network organization. Bitwarden organizes secrets in groups called Collections and within those Collections are four User Types: User, Manager, Admin, and Owner.

In order to maintain integrity of the Toronto Community Network operations, most users will be granted only User or Manager access. The Project Operations team will determine your access based on your use case or requirements.

Storing Secrets

All secrets must be attached to a Collection to facilitate access control. Please be sure to attach the secret to an existing Toronto Community Network Work Group. These collection names start with _OU.

Additional Collections may be created or utilized to classify the secret such as Social, Service Accounts, Website, and more.

When naming your credential, please use the following convention: System/Function - Identifier.

For example:

  • A public SSH key may be named "Public Key - Contributor A"
  • A GitHub deployment key may be named "GitHub - Deploy Key (docs.tomesh.net)"
  • A shared login social media may be named "Twitter - tomeshnet"

When determining a password or passphrase, please use strong entropy to prevent unauthorized access. For more information, please see our Recommended Best Practices below.

All public keys and private keys must be saved as Secured Notes.

Please be mindful that secrets stored in this system can be accessed by any authorized contributor in the Toronto Community Network. While your connection to the system is secured via TLS, the secrets you choose to store in the group can be seen by others. Please refrain from using the system for storing any personal information.

For more information about managing items, please see Bitwarden's official documentation on Managing Items.

Data Backup

The VM that hosts the Bitwarden container is backed up on a weekly basis.

Administrators of the Toronto Community Network organization have the ability to export the entire vault to a JSON or CSV file.

As the export function provides secrets in clear-text, please secure or encrypt the file immediately.

Recommended Best Practices

The Government of Canada's Canadian Centre for Cyber Security provides recommendations for organizations to protect networks, systems, and information. By using these best practices, you can protect yourself and the integrity of the Toronto Community Network.