| Version 8 (modified by , 4 years ago) ( diff ) |
|---|
Site Navigation
Policies & Compliance
Since the testbed can radiate in a wide range of RF frequencies, and uses a considerable amount of power and other resources, we require that it be used for legitimate research purposes.
Efforts have been made to prevent accidental misuse or interference with other users or the public, however deliberate abusive or malicious actions will result in a ban from access.
Accidents, mistakes, misconfigurations and the like happen. Some actions, such as transmitting on a forbidden frequency, or accidental network denial of service, will result in a warning to you, and your group administrator.
This is a shared resource, please make every effort to be considerate to other users.
Outdoor Radio Frequency Allocation
Reception in COSMOS is unrestricted on any frequency capable of being received by a given piece of hardware (refer to specific hardware details for capabilities).
Transmission on any frequency is allowed only with prior approval and limited to frequency bands authorized for such use by the FCC. In addition to the unlicensed ISM bands (subject to regulation by part 15 of the FCC rules), the following bands are available for use by the outdoor COSMOS deployment as part of the New York City Innovation Zone as designated by the FCC.
| Frequency Band | Type of operation | Allocation | Maximum EIRP (dBm) |
|---|---|---|---|
| 2500-2690 MHz | Fixed | Non-federal | 20 |
| 3700-4200 MHz | Mobile | Non-federal | 20 |
| 5850-5925 MHz | Mobile | Shared | 20 |
| 5925-7125 MHz | Fixed & Mobile | Non-federal | 20 |
| 27.5-28.35 GHz | Fixed | Non-federal | 20 |
| 38.6-40.0 GHz | Fixed | Non-federal | 20 |
Program Experiment License
Spectrum Monitoring
Each Node has, at minimum, one SDR for spectrum monitoring, and one for experiment usage, although they can be configured independently.
Their external RF frontends contain filters, to restrict transmission to allowed bands. The filters are configured by a central service, disallowing experimenters from selecting unacceptable frequencies and power levels.
Emergency Stop Procedures
All transmit capable devices have either a method to either disconnect the RF front-end, cut the power entirely, or both.
In the event of an emergency, the testbed operators can hard power off any offending device.
In the event of an issue with the central co-ordination service, watchdogs on each node will, after a short timeout, automatically power off the RF components.
Network and Platform Security
External Network Access
Only authenticated users can log in to the Consoles and and other SSH jump hosts. We assume that the user connecting with a given SSH key is the same user that uploaded it to the portal.
Important The user takes all responsibility for safeguarding their local SSH keys. Best practices, such as strong passphrases should be followed.
Our SSH endpoints are configured following the Mozilla best practices guidelines.
VPN access is similarly gated on the testbed access credentials. SSH and VPN connections may only be initiated during a reservation, and are closed automatically at the end of said reservation.
All externally facing machines are behind a firewall, as well as having their own security mechanisms configured.
To access their own files, or the testbed resources, a user has to connect through one of the configure Jump Hosts. All Jump Hosts log user access to a central location.
Internal Network Access
External Access, Experiment Control, and Experiment Dataplane networks are isolated with VLANs and ACLs on the core network switches.
To connect to Domain Resources, a User must pass through the Domain's Console.
Shared Machines
User data is safeguarded by standard POSIX permissions. Safe defaults have been set, but it is the users' responsibility to avoid running untrusted code, or setting their own files to world writable.
Shared machines are treated as if public, from a security perspective. It is assumed that all connections, both from external networks, and from experiment networks, are untrusted by default.
Cron jobs or other long running commands are permitted after the end of a reservation, as the management process will kill all processes spawned by said user.
Testbed Compute resources
Within a Domain, and during their Reservation, users have full rights to the Compute Resources, and have both root and serial console access.
These machines are insecure by default, except for these factors:
- No network access from outside. A combination of a stateful firewall and NAT prevents external entities from initiating connections. This is the standard assumption for say, a properly configure Home LAN.
- No access between experiment networks, unless configured. Users are able to manually bridge networks, during their reservation, if they have the relevant rights. Users must act according to their own security model.
When a compute resource is provisioned, the disk is overwritten. At the same time, if sensitive information is saved to disk, it is the experimenter's responsibility to erase the disk with our provided commands.
