Version 6 (modified by Josh Smift, 10 years ago) (diff)


GENI rack security

This page has some general information about security in the context of the various GENI racks. Detailed security information is also available from each rack team or rack vendor.

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. a campus network) 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 local device(s) 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