JK
J. Kerkhof
info
Please Note
<p>This page displays the records of the person named above and is not linked to a unique person identifier. This record may need to be merged to a profile.</p>
2 records found
1
Design for a TCP/IP transparent FPGA-based network diode
To what extent is it possible to implement a network diode on an FPGA under realistic network environments, using the Transmission Control Protocol?
Master thesis
(2021)
-
Jorden Kerkhof, J.S.S.M. Wong, A.J. van Genderen, T.G.R.M. van Leuken, A.D. Wiersma
The urgency for high-security products for industrial networks is increasing as malicious hackers are improving their accessibility tools. A common practice for a company to protect its sensitive data is network segmentation. The network is segmented in different domains with distinctive security levels. The sensitive data is stored and managed within the domain of the highest security level. To access this domain from another domain of a lower security level, a highly reliable connection is required. You want to have full control over the incoming and outgoing data flow between these network segments. A variety of solutions provide a highly-secured connection to link those segments which differ in range of features and control. An upcoming trend is the network diode. This device will allow data flow in only one direction. All the flows going into the opposite direction are being blocked. However, to feature an arbitrary flow between two network segments, the diode should consist of a numerous amount of properties. To narrow down the optional features a network diode should provide, this thesis will focus on TCP streams. TCP is one of the most common protocols used in internet traffic. Furthermore, TCP is a challenging protocol as it is a connection-oriented bidirectional protocol, which is intrinsic controversial with the concept of the data diode. To ensure the security of the data diode, this thesis will focus on a complete hardware design of the data diode. Software inside the data diode is still a risk for a security breach. This thesis will investigate the critical operations of TCP to implement them in the data diode. The aim is to utilise TCP's characteristic operations of the acknowledgement managing, the sliding window system, the congestion control algorithm, and explores the advantage of existing TCP options. To evaluate the feasibility of a high performance data diode featuring TCP, the system is broken down to project the behaviour of a TCP stream on a one-way connection device. This results in two separate TCP connections, with only the precious data as common shared information. This model requires a buffer at one side of the diode to transmit data in a TCP stream. To analyse and examine the influence of the diode configuration to the size of the buffer, a diode module is created to simulate in a OMNeT++ environment. From this simulation tool, a minimal set of parameters can be extracted that are essential to configure the data diode. With the assumption of having control on the network management at the trusted side of the diode, a configuration without a congestion control algorithm and without adding radical TCP options is recommended to minimise the required buffer size. Thereafter, this thesis proposes a high-level hardware design to implement the data diode on a hardware project. The design focuses on the high data rate which should be available to satisfy the data diode's requirements. Finally, this thesis concludes with an elaboration on the assumptions of the limitations of the network environments and recommends features to implement in future work.
...
The urgency for high-security products for industrial networks is increasing as malicious hackers are improving their accessibility tools. A common practice for a company to protect its sensitive data is network segmentation. The network is segmented in different domains with distinctive security levels. The sensitive data is stored and managed within the domain of the highest security level. To access this domain from another domain of a lower security level, a highly reliable connection is required. You want to have full control over the incoming and outgoing data flow between these network segments. A variety of solutions provide a highly-secured connection to link those segments which differ in range of features and control. An upcoming trend is the network diode. This device will allow data flow in only one direction. All the flows going into the opposite direction are being blocked. However, to feature an arbitrary flow between two network segments, the diode should consist of a numerous amount of properties. To narrow down the optional features a network diode should provide, this thesis will focus on TCP streams. TCP is one of the most common protocols used in internet traffic. Furthermore, TCP is a challenging protocol as it is a connection-oriented bidirectional protocol, which is intrinsic controversial with the concept of the data diode. To ensure the security of the data diode, this thesis will focus on a complete hardware design of the data diode. Software inside the data diode is still a risk for a security breach. This thesis will investigate the critical operations of TCP to implement them in the data diode. The aim is to utilise TCP's characteristic operations of the acknowledgement managing, the sliding window system, the congestion control algorithm, and explores the advantage of existing TCP options. To evaluate the feasibility of a high performance data diode featuring TCP, the system is broken down to project the behaviour of a TCP stream on a one-way connection device. This results in two separate TCP connections, with only the precious data as common shared information. This model requires a buffer at one side of the diode to transmit data in a TCP stream. To analyse and examine the influence of the diode configuration to the size of the buffer, a diode module is created to simulate in a OMNeT++ environment. From this simulation tool, a minimal set of parameters can be extracted that are essential to configure the data diode. With the assumption of having control on the network management at the trusted side of the diode, a configuration without a congestion control algorithm and without adding radical TCP options is recommended to minimise the required buffer size. Thereafter, this thesis proposes a high-level hardware design to implement the data diode on a hardware project. The design focuses on the high data rate which should be available to satisfy the data diode's requirements. Finally, this thesis concludes with an elaboration on the assumptions of the limitations of the network environments and recommends features to implement in future work.
HedoN is a high-tech electronic development and production company that tasked a group of six TU Delft Electrical Engineering bachelor students to design a simulation system for hydraulic plants. This simulation system consist out of a central Hydraulic Simulation Unit (HSU) that runs a hydraulics simulation and controls various electrical components. This thesis describes the Ethernet communication between that HSU and the electrical components.
As per Requirement 4, the communication system has to be designed to operate on a 1 millisecond tick. Every millisecond the HSU communicates new data with the various electrical components. This data consists of currents, voltages and operation modi for the components. Various Ethernet protocols were considered and in the end raw Ethernet communication on the OSI data link layer was selected. This is the most lightweight possible communications protocol through Ethernet to ensure the communication is fast enough and lightweight on processing power.
Every millisecond the HSU broadcasts a big packet with all the data to every component. These components will then extract information relevant to their operation. This design choice moves the computational effort of selecting relevant data per component from the HSU to the components. This is desirable since the HSU needs enough processing power to run the simulation as well as the communication in parallel. The components will then process the data and provide their response with unicast packets.
For every component to know exactly what data from the broadcasted packet is relevant to them, an initialisation phase is required. This phase is executed before the 1ms tick communication and ensures the components know at what offset they can find their relevant data.
This communication system was then tested to check if it does meet the 1ms requirement. It turns out the communication has some issues achieving the 1ms Requirement 4. The problem could be the non-realtimeness of the Linux kernel running on the HSU which leads to packets not meeting the 1ms requirement. A possible solution to this problem would be to program the HSU on a realtime OS or even baremetal C. ...
As per Requirement 4, the communication system has to be designed to operate on a 1 millisecond tick. Every millisecond the HSU communicates new data with the various electrical components. This data consists of currents, voltages and operation modi for the components. Various Ethernet protocols were considered and in the end raw Ethernet communication on the OSI data link layer was selected. This is the most lightweight possible communications protocol through Ethernet to ensure the communication is fast enough and lightweight on processing power.
Every millisecond the HSU broadcasts a big packet with all the data to every component. These components will then extract information relevant to their operation. This design choice moves the computational effort of selecting relevant data per component from the HSU to the components. This is desirable since the HSU needs enough processing power to run the simulation as well as the communication in parallel. The components will then process the data and provide their response with unicast packets.
For every component to know exactly what data from the broadcasted packet is relevant to them, an initialisation phase is required. This phase is executed before the 1ms tick communication and ensures the components know at what offset they can find their relevant data.
This communication system was then tested to check if it does meet the 1ms requirement. It turns out the communication has some issues achieving the 1ms Requirement 4. The problem could be the non-realtimeness of the Linux kernel running on the HSU which leads to packets not meeting the 1ms requirement. A possible solution to this problem would be to program the HSU on a realtime OS or even baremetal C. ...
HedoN is a high-tech electronic development and production company that tasked a group of six TU Delft Electrical Engineering bachelor students to design a simulation system for hydraulic plants. This simulation system consist out of a central Hydraulic Simulation Unit (HSU) that runs a hydraulics simulation and controls various electrical components. This thesis describes the Ethernet communication between that HSU and the electrical components.
As per Requirement 4, the communication system has to be designed to operate on a 1 millisecond tick. Every millisecond the HSU communicates new data with the various electrical components. This data consists of currents, voltages and operation modi for the components. Various Ethernet protocols were considered and in the end raw Ethernet communication on the OSI data link layer was selected. This is the most lightweight possible communications protocol through Ethernet to ensure the communication is fast enough and lightweight on processing power.
Every millisecond the HSU broadcasts a big packet with all the data to every component. These components will then extract information relevant to their operation. This design choice moves the computational effort of selecting relevant data per component from the HSU to the components. This is desirable since the HSU needs enough processing power to run the simulation as well as the communication in parallel. The components will then process the data and provide their response with unicast packets.
For every component to know exactly what data from the broadcasted packet is relevant to them, an initialisation phase is required. This phase is executed before the 1ms tick communication and ensures the components know at what offset they can find their relevant data.
This communication system was then tested to check if it does meet the 1ms requirement. It turns out the communication has some issues achieving the 1ms Requirement 4. The problem could be the non-realtimeness of the Linux kernel running on the HSU which leads to packets not meeting the 1ms requirement. A possible solution to this problem would be to program the HSU on a realtime OS or even baremetal C.
As per Requirement 4, the communication system has to be designed to operate on a 1 millisecond tick. Every millisecond the HSU communicates new data with the various electrical components. This data consists of currents, voltages and operation modi for the components. Various Ethernet protocols were considered and in the end raw Ethernet communication on the OSI data link layer was selected. This is the most lightweight possible communications protocol through Ethernet to ensure the communication is fast enough and lightweight on processing power.
Every millisecond the HSU broadcasts a big packet with all the data to every component. These components will then extract information relevant to their operation. This design choice moves the computational effort of selecting relevant data per component from the HSU to the components. This is desirable since the HSU needs enough processing power to run the simulation as well as the communication in parallel. The components will then process the data and provide their response with unicast packets.
For every component to know exactly what data from the broadcasted packet is relevant to them, an initialisation phase is required. This phase is executed before the 1ms tick communication and ensures the components know at what offset they can find their relevant data.
This communication system was then tested to check if it does meet the 1ms requirement. It turns out the communication has some issues achieving the 1ms Requirement 4. The problem could be the non-realtimeness of the Linux kernel running on the HSU which leads to packets not meeting the 1ms requirement. A possible solution to this problem would be to program the HSU on a realtime OS or even baremetal C.