81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
* Community-Lab testbed architecture
** Overall architecture
This architecture applies to all testbeds using the CONFINE software.
# Move over overlay diagram less overlay connections plus overlay network.
- A testbed consists of a set of nodes managed by the same server.
- Server managed by testbed admins.
- Network and node managed by node admins (usually node owners).
- Node admins must adhere to a set of conditions.
- Solves management vs. ownersip problem.
- All components in testbed reachable via management network (tinc mesh VPN).
- Avoids problems with firewalls and private networks in nodes.
- Avoids address scarcity and incompatibility (well structured IPv6 schema).
- Public CN addresses still used for experiments when available.
- Gateways connect disjoint parts of the management network.
- Allows a testbed spanning different CNs and islands through external means
(e.g. FEDERICA, the Internet).
- A gateway reachable from the Internet can expose the management network
(if using public addresses).
- A researcher runs the experiments of a slice in slivers each running in a
different node…
** Nodes, slices and slivers
- …a model inspired in PlanetLab.
- The slice (a management concept) groups a set of related slivers.
- A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
allocated for a slice in a given node.
# Diagram: Slices and slivers, two or three nodes with a few slivers on them,
# each with a color identifying it with a slice.)
** Node architecture
Mostly autonomous, no long-running connections to server, asynchronous
operation: robust under link instability.
# Node simplified diagram, hover to interesting parts.
- The community device
- Completely normal CN network device, possibly already existing.
- Routes traffic between the CN and devices in the node's local network
(wired, runs no routing protocol).
- The research device
- More powerful than CD, it runs OpenWrt firmware customized by CONFINE.
- Experiments run here. The separation between CD and RD allows:
- Minumum CONFINE-specific tampering with CN hardware.
- Minimum CN-specific configuration for RDs.
- Greater compatibility and stability for the CN.
- Slivers are implemented as Linux containers.
- LXC: lightweight virtualization (in Linux mainstream).
- Provides a familiar env for researchers.
- Easier resource limitation, resource isolation and node stability.
- Control software
- Manages containers and resource isolation through LXC tools.
- Ensures network isolation and stability through traffic control (QoS)
and filtering (from L2 upwards).
- Protects users' privacy through traffic filtering and anonimization.
- Optional, controlled direct interfaces for experiments to interact
directly with the CN (avoiding the CD).
- The recovery device can force a hardware reboot of the RD from several
triggers and help with upgrade and recovery.
** Node and sliver connectivity
# Node simplified diagram, hover to interesting parts.
Slivers can be configured with different types of network interfaces depending
on what connectivity researchers need for experiments:
- Home computer behind a NAT router: a private interface with traffic
forwarded using NAT to the CN. Outgoing traffic is filtered to ensure
network stability.
- Publicly open service: a public interface (with a public CN address) with
traffic routed directly to the CN. Outgoing traffic is filtered to ensure
network stability.
- Traffic capture: a passive interface using a direct interface for capture.
Incoming traffic is filtered and anonymized by control software.
- Routing: an isolated interface using a VLAN on top of a direct interface.
It only can reach other slivers of the same slice with isolated interfaces
on the same link. All traffic is allowed.
- Low-level testing: the sliver is given raw access to the interface. For
privacy, isolation and stability reasons this should only be allowed in
exceptional occasions.
|
|
|
|
|
|
|
|
|
|
|
<
<
<
|
|
|
<
<
>
>
|
|
<
>
>
|
|
>
|
|
|
|
|
<
<
|
<
|
<
|
|
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
* Community-Lab testbed architecture
** Overall architecture
This architecture applies to all testbeds using the CONFINE software.
# Move over overlay diagram less overlay connections plus overlay network.
- A testbed consists of a set of nodes managed by the same server.
- Server managed by testbed admins.
- Network and node managed by node admins (usually owners and CN members).
- Node admins must adhere to testbed conditions.
- This decouples testbed management from infrastructure ownership and mgmt.
- Testbed management traffic uses a tinc mesh VPN:
- Avoids problems with firewalls and private networks in nodes.
- Uses IPv6 to avoid address scarcity and incompatibility between CNs.
- Short-lived mgmt connections make components mostly autonomous and
tolerant to link instability.
- A testbed can span multiple CNs thanks to gateways.
- Bridging the mgmt net over external means (e.g. FEDERICA, the Internet).
- Gateways can route the management network to the Internet.
- A researcher runs the experiments of a slice in slivers each running in a
different node…
** Nodes, slices and slivers
- …a model inspired in PlanetLab.
- The slice (a management concept) groups a set of related slivers.
- A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
allocated for a slice in a given node.
# Diagram: Slices and slivers, two or three nodes with a few slivers on them,
# each with a color identifying it with a slice.)
** Node architecture
# Node simplified diagram, hover to interesting parts.
- The community device
- Completely normal CN device, so existing ones can be used.
- Routes traffic between the CN and devices in the node's wired local
network (which runs no routing protocol).
- The research device
- Usually more powerful than CD, since experiments run here.
- Separating CD/RD makes integration with any CN simple and safe:
- Little CONFINE-specific tampering with CN infrastructure.
- Little CN-specific configuration for RDs.
- Misbehaving experiments can't crash CN infrastructure.
- Runs OpenWrt firmware customized by CONFINE.
- Slivers are implemented as Linux containers.
- Lightweight virtualization supported mainstream.
- Provides a familiar and flexible env for researchers.
- Direct interfaces allow experiments to bypass the CD when interacting with
the CN.
- Control software
- Uses LXC tools on containers to enforce resource limitation, resource
isolation and node stability.
- Uses traffic control, filtering and anonymization to ensure network
stability, isolation and privacy.
- The recovery device can force a hardware reboot of the RD from several
triggers and help with upgrade and recovery.
** Node and sliver connectivity
# Node simplified diagram, hover to interesting parts.
Slivers can be configured with different types of network interfaces depending
on what connectivity researchers need for experiments:
- Home computer behind a NAT router: a private interface with traffic
forwarded using NAT to the CN and filtered to ensure network stability.
- Publicly open service: a public interface (with a public CN address) with
traffic routed directly to the CN and filtered to ensure network stability.
- Traffic capture: a passive interface using a direct interface for capture.
Incoming traffic is filtered and anonymized to ensure network privacy.
- Routing: an isolated interface using a VLAN on top of a direct interface.
It only can reach other slivers of the same slice with isolated interfaces
on the same link. All traffic is allowed.
- Low-level testing: the sliver is given raw access to the interface. For
privacy, isolation and stability reasons this should only be allowed in
exceptional occasions.
|