Thesis: Achieving application-level requirement-based path selection within SCION

One interesting aspect of SCION is that it allows for path-aware networking (PAN). So, for example, an application can decide what path through the network its packets are supposed to take. That allows for new opportunities to increase the security and resilience of network communications by increasing transparency for endpoints and making it possible to avoid potentially insecure paths. For example, you can choose a path that only has routers with a specific security patch, or a path that always stays within the EU. The ability to choose a path based on a set of security requirements is a benefit for many sectors. For instance, in the medical sector, a path may be required that ensures a very stable connection for use in remote surgery, or paths that stay entirely in trusted countries.

For my research, I investigated how application-level requirement-based path-aware networking can be achieved on the SCION network. To do that, I did a literature study and created an application design for a remote surgery use case. The use case allowed me to better investigate different types of requirements. I also implemented a prototype of the design to test its feasibility.

Application design

Remote surgery imposes several requirements on the network, making it an interesting use case for PAN. First, the network must always be available, as loss of availability during remote surgery can have severe consequences. Second, the network must ensure integrity, because the potential for outside interference with control of the surgical robot is unacceptable. Also, confidentiality must be ensured, as healthcare data is sensitive. Lastly, the network must be resilient against attacks of several kinds, such as denial-of-service attacks, IP spoofing and eavesdropping.

To test whether PAN can fulfil those requirements, we developed the following application.

The application is present on two devices: a controller used by the remote surgeon, and a receiver connected to a camera and a surgical robot. The controller has several features: a policy selector so different path requirements can be set, an indicator to show whether the current path meets the requirements, and a method for commanding the receiver to send instructions to the surgical robot. The receiver runs without human interaction and simply processes the incoming commands.

The controller application initialises the connection by going through several steps before sending the first data packet:

1. First it finds all possible paths to the receiver and extracts various path properties.

2. Using the preference policy, a ranking is created of all paths. The best path is then chosen.

3. A connection is then set up using that path. The connection’s compliance is actively monitored and, if a better path becomes available, the controller will switch to it.

4. As an option, multi-path mode can be enabled, which allows a second connection to be set up transparently using a different path, so that data packets still arrive if the primary path suffers performance loss.

For the property extraction, I looked at four different properties: latency, bandwidth, geolocation and router firmware version. Latency and bandwidth were straightforward to measure by active means. For geolocation, we decided to filter based on ISDs, as SCION uses a logical grouping of the ASes within ISDs, often with a strong location-based connection. Router firmware version was a bigger challenge. SCION does not offer a native method to extract or verify static information beyond geolocation. Without modifying SCION, our only method of extracting this information was through utilisation of the path metadata, but that is not ideal. In a real-life scenario, many ASes may be unwilling to include such information in their metadata, and even if they do, there is currently no native method to verify correctness.

For the automatic path selection, we used the Reference Ideal Method (RIM), which is a multiple-criterion decision-making method. In short, it is a way to decide where selection of the best alternative is complex. With RIM, you can set “ideals”, which define the range you want your property to be in. For example, you might want path latency to be 100ms or less, or you might want only paths that go through ISD 1, 2 and 4. Using the defined ideals, path requirements can be set. In our use case, availability is more important than meeting all the requirements, so if no path exists that meets all the requirements, the path with the highest availability is identified.

Because availability is so important, I also included a multi-path mode. That involved choosing between redundant multi-path mode and adaptive multi-path mode. In redundant multi-path mode, traffic is always sent over two paths to guarantee availability, whereas with adaptive multi-path mode a second path is used only when the performance of the primary path is below a threshold. One thing I had to consider was that the best paths within the RIM ranking are likely to be very similar paths where maybe only 1 AS is different. Therefore, if an AS goes offline, there is a high chance all paths will go offline when using the redundant mode. Therefore, for our use case, adaptive multi-path mode is more suitable since the ranking would change the moment the best path exhibits performance loss.

Test setup and results

The test setup consisted of two laptops running the application. The client laptop ran the client application, a local MongoDB server where all paths were stored, and the SCION AS connected to the Carnegie Mellon University (CMU) attachment point. It also ran a modified version of the UPIN Project’s tool to collect all the paths and extract the different properties. The second laptop ran the receiver application, a BWTester Server so the bandwidth could be tested, and the SCION AS connected to the Magdeburg attachment point. The full topology can be seen in Figure 1.

Figure 1. Topology of the test setup of the prototype.

I performed several tests to measure the efficiency of the solution. The path collection stage only took around 2 to 3 seconds. However, property extraction, where I gathered information such as latency and bandwidth, took much longer. Figure 2 shows the time it took to do one property extraction run, depending on the number of paths and the client AS. With 40 paths, the ideal number of paths, property extraction can easily take around 9 minutes. That is not ideal, because it means the path’s health status gets updated only once every 9 minutes, although path health can change drastically in that time. While running the tests, the system also got stuck sometimes and needed manual intervention to restart it. I suspected there was a bug in one of the measuring tools I used.

Figure 2. A comparison of path extraction runs in seconds with the US AS (18 and 40 paths) and the Swiss AS (40 paths).

I also tested the efficiency of the path selection itself, specifically the time it took to load the preference policy file and the gathered path properties, and to rank the paths accordingly. Our requirements are set in a preference policy file. First, I took a baseline without a set policy, which resulted in a selection time of 10 seconds. When we set a preference policy, it took around 16 seconds to select a path. That implies that setting a preference policy and creating a path ranking took around 6 seconds. If we set a preference policy and enabled multi-path mode, the average time was around 29 seconds, which is significantly higher. However, I suspect that those times can be improved upon by making some code optimisations.

Future research

As it stands, PAN within SCION is an interesting feature, but we recommend adding to its capabilities, so that more path properties can be extracted and verified. Currently, non-quantifiable properties are difficult to verify, or their verification is not supported. One possibility is to enable FABRID to run natively on SCION. Alternatively, a new method could be identified by carrying out more research. I also recommend enabling the client to verify whether a packet it has sent did in fact travel along the selected path. While SCION has some native validation capability, it does not offer end-host path validation. One method that could be utilised is EPIC (Every Packet Is Checked), which allows end hosts to perform path validation. With those additional capabilities, PAN could greatly improve the security of network communication.

Read my full research paper 'Achieving application-level requirement-based path selection with SCION'.