Controlled eXternal Access

This note attempts to give some information for using the new Controlled eXternal Access sytem (CXA).

CXA attempts to be backwards compatible with experiments created under the previous Risky Experiment mechanism, but gives some additional capabilites.

Dynamic modification/access

If you have an an existing experiment, and you want to grant it external access, you can do so , even if it is already swapped in, without restarting the experiment.

You use a web page https://<testbed>/expcxa.php?pid=<pid>&eid=<eid> and fill out the same form that is used by the "Make Experiment Risky" page, parsed with almost the same rules.

For Outside nodes - triples <dotted quad>/<port>/<proto>, It is now permitted to specify a host of 0.0.0.0 (meaning any IP address), and/or a port number of 0, (meaning any port).

In the future, but not now, we would like to have the host part be regular DNS names, or to allow the use of commas as separators instead of slashes so that the hostpart could be an IP subnet.

There is also a bug that you have to click the check the box for "Experiment need outside connetctivity" even if you've already granted it.

If your experiment already has specified nodes with external connectivity in its ns file, it will issue commands to reconfigure the LAST external node in your nsfile, instead of the shared gateway, if the node is running some flavor of BSD; otherwise it just modifies the risky experiment tables in the database.

NS file extensions for shared external access

We have made a minor change to the parsing of the ns extension

    tb-allow-external $node [<cookietype> [key1 value1] [key 2 value2] .... ]

if the cookieype is "shared", then only the keyN valueN pairs will be entered in virt parameters table, and no pseudonode with vname external_ipaddr<N> will be requested by the experiment.

The CXA backend will examine the virtual parameters whenever an an ns file is (re-)parsed and will (re-)initialize the risky experiment table entries for the experiment based on the values for two keys, namely "nat" and "rdr".

The values are a quoted string of whitespace separated targets, such as the slash delimited triples that can be entered in section 1 above.

Alterations made by the webpage above persist only until modifyexp or endexp is run on the testbed.

We allow some abbreviations for convience.

For "rdr" targets, one may use triples as in the web page.

For pairs, the target is interpreted as be <port>/<proto>, and the node part is assumed to be the node specified in the tb-allow-external call.

For singletons, it is assumed to be <port> which the <proto> defaulting to tcp.

For "nat" targets, one may use triples as in the web page.

Pairs are interpreted as <host>/<port>, the proto defaulted to tcp. and singletons, it is assumed to be <host> which the <proto> defaulting to tcp and the <port> default to 0 meaning all ports.

DNS stuff

In the interest of backwards compatibility, even when using "shared" external access there will still be a CNAME created for each node named with a tb-allow-external call. The value will be the IP address of the shared NAT box.

Additionally, any nodes designated as targets of inbound redirects will also have CNAMEs created for them, whether or not the targets were created dynamically via a web page, or statically in the NS file. If all targets for a node specified in the NS file were removed via the web, then no CNAME will be generated.