Version 2 (modified by, 7 years ago) (diff)

use help mailing list instead of infra list

GENI rack security

This page has some information about security in the context of the various GENI racks.

Dataplane network security

Each GENI rack has a dataplane switch, which carries the traffic from experimenters in their GENI experiments. This switch is connected to the GENI network core, but also to a local network (e.g. something on-campus) at each GENI rack site. This raises the possibility that traffic from GENI experiments could flow from the rack onto a site's regular network.

If at any point a site admin detects unwanted traffic flowing onto their network, they can and should feel free to block that traffic, and ideally report the issue to the GENI Meta-Operations Center (GMOC). Some ways to do that:

  • Simple ACLs on the device that the rack dataplane switch connects to. These could be set up in advance to prevent known unwanted traffic, or configured in response to an incident to block unexpected traffic.
  • A separate network firewall device in the path between the switch and the site network. Since the rack dataplane switches are intended to operate at gigabit-plus speeds, sites should take care to ensure that such a firewall device can handle that level of throughput.
  • Configuration on the dataplane switch itself. The dataplane switch should not generally be configured by site admins to enforce local security policies proactively, but simple configuration changes in response to an incident (like configuring ports on the switch to be administratively down) may be useful at times.
  • Configuration of resource approval. The rack software stack includes GENI aggregate managers that grant experimenters access to the rack's resources, including the dataplane switch. In general, requests from experimenters for rack resources are automatically granted (if resources are available), but the rack's OpenFlow aggregate manager (FOAM) can be configured to hold experimenter requests by default, and only approve them if an admin manually authorizes the request. This makes the OpenFlow resources on the rack much harder for experimenters to use, but it is an available configuration if a site admin deems it necessary. This isn't an option for the non-OpenFlow resources in the rack, so the scope of this approach is also fairly limited.

If you have any questions or concerns, don't hesitate to contact the infrastructure support team (