Version 10 (modified by seskar, 7 weeks ago) ( diff )

RF 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 BandType of operationAllocationMaximum 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 NOT 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.

Note: See TracWiki for help on using the wiki.