79 lines
11 KiB
TeX
79 lines
11 KiB
TeX
\chapter{Preliminaries}
|
|
\label{chap:preliminaries}
|
|
|
|
In this chapter, the necessary background and foundational concepts underlying the research presented in this thesis are introduced. First, the theoretical frameworks and methodologies guiding the approach are discussed, followed by an overview of the key technologies and tools used in this work. The chapter is intended to establish a common understanding and provide context for the subsequent chapters, in which the specific contributions and findings of the research are presented.
|
|
|
|
\section{\ac{OSI} Model}
|
|
\label{sec:osi}
|
|
|
|
The \ac{OSI} Basic Reference Model provides a conceptual framework for describing communication between open systems in a structured and interoperable way. Instead of treating network communication as a single process, it divides it into seven layers with clearly separated responsibilities. This layered view simplifies the analysis of communication systems and provides a common terminology for discussing protocols and interfaces.
|
|
|
|
The \ac{OSI} model is not itself a concrete protocol suite, but rather a reference architecture. It does not prescribe which technologies must be used in practice. Instead, it provides a general structure that can be used to classify communication functions and to explain how different protocols relate to one another. Each layer offers services to the layer above while relying on the services of the layer below.
|
|
|
|
\subsection{Physical Layer}
|
|
|
|
The Physical Layer is concerned with the transmission of raw bit streams over the physical medium. It defines how signals are represented and transferred, for example over cables, optical fibers, or wireless links. It therefore forms the foundation of all higher-level communication.
|
|
|
|
\subsection{Data Link Layer}
|
|
|
|
The Data Link Layer organizes the raw bits received from the Physical Layer into structured units and supports communication between adjacent nodes on the same link. It is responsible for local addressing, medium access control, and error detection on the local transmission path.
|
|
|
|
\subsection{Network Layer}
|
|
|
|
The Network Layer enables communication beyond a single local link. It provides logical addressing and routing functions that allow data to be forwarded across interconnected networks from a source to a destination.
|
|
|
|
\subsection{Transport Layer}
|
|
|
|
The Transport Layer provides end-to-end communication services between application entities in different systems. Depending on the protocol and service model, this can include segmentation, reassembly, flow control, and error recovery.
|
|
|
|
\subsection{Session Layer}
|
|
|
|
The Session Layer is responsible for establishing, managing, and terminating communication sessions between applications. It structures the dialogue between communicating systems and can support synchronization during longer exchanges.
|
|
|
|
\subsection{Presentation Layer}
|
|
|
|
The Presentation Layer deals with the representation of data. It ensures that information exchanged between systems can be interpreted correctly even when internal data formats differ. Typical functions include formatting, translation, and related representation issues.
|
|
|
|
\subsection{Application Layer}
|
|
|
|
The Application Layer is the highest layer of the model and contains the communication functions used directly by application processes. It forms the interface between the communication system and the software that uses network services.
|
|
|
|
\subsection{Layered Structure and Function}
|
|
|
|
A key principle of the \ac{OSI} model is that each layer has a defined scope of responsibility and interacts mainly with the layers directly above and below it. This reduces complexity and supports standardization by allowing communication functions to be discussed separately while still being part of one overall architecture.
|
|
|
|
For the present thesis, the \ac{OSI} model is mainly used as a conceptual orientation for the discussion of communication layers and network functions. Even though the implemented system is better described using the practical \ac{TCP}/\ac{IP} stack, the \ac{OSI} structure remains useful for introducing the general principles of layered communication.
|
|
|
|
\section{Linux Kernel Networking}
|
|
\label{sec:linux-kernel-networking}
|
|
|
|
In Linux, networking is handled by a subsystem that spans user space sockets, protocol implementations, filtering and routing logic, network devices, device drivers, and the network interface card. A packet therefore does not move directly from an application to the transport medium or the other way around. Instead, it passes through a sequence of kernel-controlled processing stages on the egress and ingress paths \cite{stephan2024packetpath,linuxkernelnetworkingdocs}.
|
|
|
|
A central data structure of this subsystem is \texttt{sk\_buff}. In Linux, \texttt{sk\_buff} is the main networking structure representing a packet, but it does not itself contain the packet bytes. Instead, it stores metadata and pointers to associated buffers that hold headers and payload. This design allows Linux to add, inspect, and remove headers efficiently by moving pointers rather than copying the entire packet, and it also enables efficient cloning when multiple processing stages need access to the same packet data \cite{linuxkernelskbuffdocs,stephan2024packetpath}.
|
|
|
|
\subsection{Layers of a Packet}
|
|
|
|
On an Ethernet-based system, a packet on the wire is processed as a stack of protocol layers. At the data link layer, the frame contains the Ethernet header with source and destination \ac{MAC} addresses and an EtherType field. Above this follows the network-layer header, for example an IPv4 header. On top of that is the transport-layer header, such as \ac{TCP} or \ac{UDP}. The remaining bytes form the payload delivered to the application. In Linux, lower-layer headers are added on the egress path when the packet moves toward the wire, whereas they are validated and stripped on the ingress path when the packet moves toward the socket \cite{stephan2024packetpath}. When a Linux system operates as a bridge, forwarding decisions are made at Layer 2 on the basis of the destination \ac{MAC} address, that is, before local delivery to higher layers becomes necessary \cite{linuxkernelbridgedocs}.
|
|
|
|
\subsection{Egress Path}
|
|
|
|
The egress path begins in user space when an application writes data to a socket, for example by using \texttt{write()}, \texttt{send()}, or \texttt{sendto()}. For IPv4 communication, such a socket is typically an \texttt{AF\_INET} socket. The system call enters the kernel and reaches the socket layer, where \texttt{sock\_sendmsg()} retrieves the socket context and forwards the packet to the transport-layer handler. At this point, Linux may already apply security-related checks through Linux Security Modules \cite{stephan2024packetpath}.
|
|
|
|
At the transport layer, Linux constructs the transport header and prepares the packet for transmission. For \ac{TCP}, the kernel segments data if necessary, writes it into \texttt{sk\_buff} structures, enqueues it in the socket write queue, builds the \ac{TCP} header, and enforces protocol mechanisms such as maximum segment size, congestion control, and retransmission timers. For \ac{UDP}, the processing path is simpler: the kernel builds the datagram and corresponding transport header with less state and less locking overhead \cite{stephan2024packetpath}.
|
|
|
|
After transport-layer preparation, the packet enters the IP layer. Here Linux determines the route, typically by consulting the Forwarding Information Base if no suitable destination information is already cached in the packet context. Once a route is available, the kernel builds the IP header and passes the packet through netfilter hook stages such as \texttt{LOCAL\_OUT} and \texttt{POST\_ROUTING}. If necessary, Linux also resolves the next-hop destination at Layer 2, for example by using the neighbor subsystem and the \ac{ARP} to obtain the destination \ac{MAC} address. After that, the Ethernet header is added to the packet \cite{stephan2024packetpath}.
|
|
|
|
The fully constructed frame then enters the network device transmission path. Linux passes it to \texttt{dev\_queue\_xmit()}, where traffic control and queueing disciplines can process it on egress. After queueing and possible post-processing such as checksum handling or VLAN tagging, the kernel calls the driver transmission function \texttt{ndo\_start\_xmit}. The driver places the packet into the transmit ring of the network interface card, maps the packet buffer for Direct Memory Access, and the hardware finally transmits the frame onto the physical medium \cite{stephan2024packetpath}.
|
|
|
|
\subsection{Ingress Path}
|
|
|
|
The ingress path begins when the network interface card receives an Ethernet frame from the physical medium. The hardware checks link-layer conditions such as the \ac{MAC} filter and moves the received bytes into system memory by Direct Memory Access. It then notifies the operating system, which allocates an \texttt{sk\_buff} and stores metadata such as the receiving interface, protocol information, and packet type. At this stage, Linux knows the position of the Ethernet header and can record it as the \texttt{mac\_header} of the packet \cite{stephan2024packetpath,linuxkernelskbuffdocs}.
|
|
|
|
The packet is then passed into the receive path through functions such as \texttt{netif\_receive\_skb()}. During this stage, Linux can hand the packet to virtual interfaces, VLAN handling, or a receive handler associated with a master device. This is particularly relevant for bridge configurations, because an interface that is part of a Linux bridge can have its received frame intercepted for Layer-2 forwarding logic instead of immediate local delivery \cite{stephan2024packetpath,linuxkernelbridgedocs}.
|
|
|
|
If the packet is processed as an IP packet, Linux continues with \texttt{ip\_rcv()}. There, the kernel validates essential IP header fields such as version, length, and checksum, sets the pointer to the transport header, and applies the netfilter \texttt{PRE\_ROUTING} hook. The routing logic then decides whether the packet should be forwarded, locally delivered, or treated as multicast traffic. For local delivery, Linux may first reassemble fragmented packets and then applies the \texttt{LOCAL\_IN} hook before stripping the IP header and handing the packet to the appropriate transport-layer protocol handler \cite{stephan2024packetpath}.
|
|
|
|
At the transport layer, Linux validates the \ac{TCP} or \ac{UDP} header and associates the segment or datagram with the correct socket. For \ac{TCP}, this includes checksum validation, socket lookup, state-machine handling, and enqueuing the packet in the socket receive queue. For \ac{UDP}, the processing path is simpler, but it also includes checksum validation, socket lookup, and datagram consumption. Finally, when the user-space process executes a receiving system call such as \texttt{read()} or \texttt{recv()}, the kernel dequeues the data from the socket receive queue and copies it to user space \cite{stephan2024packetpath}.
|
|
|
|
For the present thesis, this complete packet path is particularly important because the developed system relies on Linux kernel mechanisms at multiple points of the communication path. The system captures traffic at Layer 2, uses bridge-based forwarding, observes and correlates packets while they traverse ingress and egress processing stages, and manipulates traffic by attaching filtering and processing logic within the kernel-controlled forwarding path.
|