{'fraction_non_alphanumeric': 0.020269300335907667, 'fraction_numerical': 0.007493324911716575, 'mean_word_length': 4.70361879810054, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Strategies for Integrating Controls Flows in Software-Defined In-Vehicle Networks and Their Impact on Network Security

Current In-Vehicle Networks (IVNs) connect Electronic Control Units (ECUs) via domain busses. A gateway forwards messages between these domains. Automotive Ethernet emerges as a flat, high-speed backbone technology for IVNs that carries the various control flows within Ethernet frames. Recently, Software-Defined-Networking (SDN) has been identified as a useful building block of the vehicular domain, as it allows the differentiation of packets based on all header fields and thus can isolate unrelated control flows. In this work, we systematically explore the different strategies for integrating automotive control flows in switched Ether-networks and analyze their security impact for a software-defined IVN. We discuss how control flow identifiers can be embedded on different layers resulting in a range of solutions from fully exposed embedding to deep encapsulation. We evaluate these strategies in a realistic IVN based on the communication matrix of a production grade vehicle, which we map into a modern Ethernet topology. We find that visibility of automotive control flows within packet headers is essential for the network infrastructure to enable isolation and access control. With an exposed embedding, the SDN backbone can establish and survey trust zones within the IVN and largely reduce the attack surface of connected cars. An exposed embedding strategy also minimizes communication expenses.

increasingly interconnected ECUs this can open new attack vectors as every gateway participating in the tunnelling layer is able to send and receive any message in that tunnel. In contrast, control messages can be directly embedded in Ethernet frames using multicast destination addresses specific to message types and domain-specific VLAN IDs. This keeps communication contexts exposed to the switching infrastructure and each vehicular control flow can be precisely identified.
Software-Defined Networking (SDN) was first introduced in campus networks [2] and promises to reduce the complexity of network control while increasing adaptability. In SDN, a central controller manages the control plane of the network. Network devices decide on the forwarding of packets based on a programmable matching pipeline managed by the controller via the OpenFlow protocol. The OpenFlow forwarding pipeline identifies network flows based on header information from layer 2 to layer 4. In recent years, use cases for SDN extended to the vehicular domain [3]. The SDN matching pipeline promises to be a powerful tool that can precisely identify and separate control flows in the network.
In this work, we compare strategies to integrate control flows in a software-defined in-vehicle Ethernet backbone and analyse their impact on the security and performance of the IVN. We compare the hidden tunneling approach with an exposed layer 2 embedding and show how identifiers of a control flow can be embedded at different layers. We evaluate the integration strategies in a realistic IVN based on the CAN network of a production car, which we transformed into a modern SDN-controlled Ethernet topology.
The remainder of this work is structured as follows. Section II reviews automotive Ethernet and related work. Section III illustrates the design space for embedding control flows in software-defined IVN and discusses the corresponding impact on network design. Security and performance evaluations of the different integration strategies are shown in Section IV. Finally, Section V concludes with an outlook on future work.

II. BACKGROUND AND RELATED WORK
Modern cars implement functions using sensors, actuators and ECUs that are linked via a combination of traditional bus systems and Ethernet technologies for newly selected links. We use CAN control flows as an example to discuss the integration of traditional bus communication into Ethernet.
In-vehicle control communication is precisely defined, and the content of messages is known. All installed ECUs and their communication relations are specified in the communication matrix of a vehicle. Each control flow in the matrix has exactly one sender, a list of receivers, and a CAN ID which is a unique vehicle wide identifier. Each ECU belongs to one domain (e.g., drivetrain) and the domain of a control flow is determined based on its sending ECU.
ECUs in current vehicles are grouped in functional domains and interconnected by proprietary bus systems. These domains often physically extend over large regions of the car. Functions based on information from different domains require messages transferred from one domain to another via a central gateway. The stepwise transition to flat Ethernet introduces processing clusters that are connected via a switched Ethernet backbone. Clusters bundle virtual functions and perform computationintensive tasks. In this work, we use a zone topology [1] which connects all legacy ECUs to a zone controller in their physical vicinity within the vehicle (e.g., front left).
In such architectures, it is essential that Quality-of-Service (QoS) guarantees are provided by the network to control concurrent mixed-critical communication. Time-Sensitive Networking (TSN) is a set of standards (see IEEE 802.1Q-2018) which extend Ethernet with the ability to forward real-timeand cross-traffic concurrently and is the leading candidate for deployment in the vehicular world.
Existing CAN-Ethernet gateway solutions embed CAN traffic in application-layer protocols. Kern et al. [4] compare aggregation strategies for automotive CAN-Ethernet gateways. For all strategies they send all messages of one CAN bus via one UDP/IP flow. AUTOSAR specifies Scalable service-Oriented MiddlewarE over IP (SOME/IP) to transport control information over Ethernet [5] and recommends embedding the traditional bus communication using the full SOME/IP header. In contrast, Herber et al. [6] evaluate sending CAN frames over AVB streams, which are now integrated in TSN. None of these approaches exposes context information about the control flows in networking protocols that are used for the forwarding decision in the network. Instead, Rumez et al. [7] integrate access control in automotive gateways that shall filter unwanted messages based on policies and attributes.
Wang et al. [8] discuss network and communication technologies for both in-vehicle and Vehicle-to-X (V2X) communication in the era of autonomous driving. They argue that more flexibility will be necessary to manage the growing dynamics of IVNs. Connected cars require new standards for cyber-security, such as specified in SAE/ISO 21434. Hu et al. [9] review secure communication approaches for IVNs including message authentication, encryption, and intrusion protection. The authors advise for the traditional protective functions such as intrusion detection, firewalling, and access control at the network transition between trust zones. We will show that the network itself can help establishing those trust zones via admission control and network separation.
Software-Defined Networking (SDN) promises to reduce the complexity of networks and increase the adaptability [10].
Shin et al. [11] review network security enhancements by SDN, for instance using central dynamic access control, network separation and firewalls. Halba et al. [3] show how SDN can improve safety and robustness of IVNs. In previous work, we examined the combination of SDN and TSN for in car networks [12]. These investigations promised that SDN can add value to the resilience, security, and adaptivity of the automotive environment, while its control overhead can be mitigated without a delay penalty in real-time communication.
Evaluating network security mechanism is always difficult as it is hard to predict the risk of unknown vulnerabilities [13]. Ruddle et al. [14] present a concept for a security analysis of automotive on-board networks. Authors derive security requirements based on dark side attack scenarios. Fundamental work on the automotive attack surface has been done by Checkoway et al. [15]. Miller and Valasek [16] analyzed the remote attack surfaces of many passenger vehicles. In later work [17], they outlined a remote attack against an unaltered 2014 Jeep Cherokee. Longari et al. [18] introduce a framework for automotive on-board network risk analysis. Based on an attack tree built from real-world incidents such as the Miller and Valasek remote exploits they evaluate how vehicle network topologies can be hardened by introducing additional gateways. Our work concentrates on reducing the attack surface by monitoring and separating network communication flows already on the MAC layer.

III. DESIGN SPACE FOR EMBEDDING CONTROL FLOWS
A Control Flow (CF) is a sequence of messages with the same identifier in the vehicle communication matrix. Sent from a single origin, it follows a point to multipoint relation to reach one or multiple receivers. The source embeds the CF identifier into packet headers, which allows receivers to identify the message context.
A Network Flow (NF) is a sequence of related packets transported from a particular source to a particular destination in the network. Using multicast a NF can reach multiple sinks simultaneously. Multicast is a common use case in IVNs, since the same information is often required at different ECUs.
Network devices identify a NF by matching packet header fields. In addition of layer 2 addressing, Ethernet switches may consider VLAN tags. Routers forward according to layer 3 addresses. The OpenFlow pipeline in SDN switches allows to match all header fields from layer 2 to layer 4. Some SDN vendors include extensions to the OpenFlow protocol which allow matching specific bytes within the transport payload. In this work, we assume that the network consists of SDN forwarding devices able to precisely match all header fields from layer 2 to layer 4.

A. Embedding Strategies for Control Flow Information
CAN-Ethernet gateways exchange data between a CAN Bus and an Ethernet network. For this purpose, the CF is repackaged between CAN and Ethernet frames. Figure 1 presents two examples for CF embedding on different layers. Each CF has an identifier, a sender, a priority, and a domain.  Depending on the repackaging, the context of the traffic can be hidden or exposed for the network.
Hidden embeddings are a common approach for repackaging in IVNs which tunnel the data using an application layer protocol. Figure 1a shows a hidden embedding that uses SOME/IP as an application-layer tunneling protocol. The CF id is embedded in the message ID field of the SOME/IP header and the data is embedded as a payload. The example uses one UDP socket per domain with reserved UDP ports for SOME/IP traffic. The IPv4 destination multicast address contains the domain identifier. The Differentiated Services Code Point (DSCP) is filled with the CF priority. The Ethernet header is automatically generated by the IP stack. The stack can be configured to map a certain DSCP to a PCP for QoS on layer 2. All CFs of one domain are sent to the same destination address, which creates a domain tunnel. The resulting NF is identified based on the sending node and the multicast destination. The destinations of the NF are the joint group of the receivers of the CFs in the tunnel.
In contrast, the repackaging can be done in a fully exposed manner. The gateway embeds the context of the CF in the packet headers, which are used for the forwarding decision in the network. Figure 1b shows an exposed embedding in the Ethernet header. It uses a raw Ethernet socket to have full control on what context information about the message is encoded on layer 2. The CF ID is encoded in the destination MAC as a multicast address. The PCP in the 802.1Q tag is used to embed the CF priority which enables QoS. A different virtual lan is created for each domain to strictly separate bus domains while maintaining the control over each message. We embed the data of the message inside the layer 2 payload. The EtherType field contains information about the embedded data type, such as a custom EtherType for CAN data frame embedding. The resulting NF identifies exactly one vehicle CF based on the multicast destination MAC address. The source and destinations of the NF are equal to sender and receivers of the transported CF.

B. Separating In-Vehicle Control Flows
The embedded context information inside the packet header fields that are used for the forwarding decision enables the network to identify which CF is transported via which NF. In this work, we compare three integration approaches for control traffic in Ethernet networks which either use a fully exposed layer 2 embedding or a hidden SOME/IP tunnel embedding. The integration approach is the key factor in how precisely CFs can be separated.
Separation by message performs a fully exposed layer 2 embedding that is used for the forwarding decision in the network. This way, each CF has its own point to multipoint NF that can be identified and separated in the network by matching the multicast destination MAC address.
Separation by domain uses the hidden SOME/IP tunneling approach and encodes a domain identifier in the destination IP address. Those domains are already in use in current vehicles for creating domain buses. The domain of a CF is selected based on the domain of its sender ECU. For each sender there is one point to multipoint NF, tunneling all CFs of one domain. The NFs can be distinguished from others by matching the source IP and multicast destination IP.
Separation by topic uses the hidden SOME/IP tunneling approach as well. Topics are groups of similar CFs. In full CAN bus architectures, each ECU belongs exactly to one domain bus. Introducing a new domain for CFs also means creating a new physical domain bus. On an Ethernet backbone, a new topic only requires a new tunnel on an existing physical link. With increasing amounts of cross-domain communication, it seems to be a good idea to introduce new fine-grained topics for CFs. Smaller groups of CFs than the original vehicle domains can thus be formed on an Ethernet backbone without the need for additional wiring. For this work, we assign custom topic identifiers to each CF in the communication matrix. We use the same topic identifier for CFs with a common context. For example, all CFs carrying motor control information are assigned to the motor control topic and all CFs regarding light control are assigned the light control topic. There are some CFs we could not group into topics. For those we create a separate topic, which only contains the one CF. The topic identifier is encoded in the multicast IP address. Each topic has one point to multipoint NF for each sender of the topic.

C. Impact on In-Vehicle Network Design
Higher layer embeddings allow the comfort of using the full IP stack. If the CF information is embedded on the application layer it can not be used for forwarding decisions without violation of the OSI model. Layer 2 information is only valid in the local IVN, so Ethernet embeddings that do not use the internet protocol are not routable. This reduces the attack surface of in-vehicle CFs.
1) Message aggregation: Aggregation is a concept to reduce overhead when relatively small control information is embedded into Ethernet. For example, a CAN message has 8 Byte payload while an Ethernet frame has a minimal size of 64 Bytes which results in 42 byte minimum payload. Kern et al. compare aggregation strategies including one-to-one mapping and buffering [4]. Buffered approaches delay messages for a certain period of time, before they are sent alone or together with other messages. The one-to-one strategy sends each  2) IP fragmentation: Packets that are larger than the maximum transfer unit of an Ethernet frame (1500 Byte) are split into multiple fragments. Only one fragment contains the transport header. Therefore, transport header fields can only be used for forwarding decisions in SDN without fragmentation. Fragment reassembly in forwarding device is not appropriate in a real-time system.
3) TSN configuration: Control information is often transmitted in cycles and with similar data size. TSN allows to control the timing of NFs by reserving bandwidth or timeslots. The reservation is more precise the better CFs can be differentiated in the network. For exposed embeddings the timing behavior can be determined much more precisely than for hidden embeddings, which results in less reservation overhead. On the other hand, the planning effort for time-slot calculation increases exponentially with an increasing number of small time-slots. Aggregation of control information makes it more difficult to calculate the timings in the network because of bursts, and varying size and period of packets. 4) Security mechanisms: An exposed embedding can help other security concepts such as network anomaly detection systems or deep packet inspection as they can monitor all mes-sages of specific CFs. Encryption might influence embedding options. The layers used for the forwarding decision should not be encrypted, e.g. the IP address can not be used when the frame is encrypted with MACSec. On the other hand, encryption might be weakened as the context of the message is visible for every receiver of the NF. 5) Device integration: If vehicles are upgraded, new functions might require the installation of new ECUs. For separation by domain or topic, new devices can join the existing tunnels. This will enable them to send and receive all CFs of this tunnel. With separation by message, new devices need to join each CF to receive them. Also, new CFs might be introduced to the network. For tunneling approaches, new CFs only require a new NF if they have a new sender or belong to a new domain/topic. With separation by message, for each new CF a new NF has to be created.

IV. EVALUATION
We now compare the different separation concepts at hand using a realistic IVN with real-world network traces. First, we evaluate the network configuration generated for our topology and each separation concept in a quantitative analysis. Second, we inspect the impact of the separation on a specific vehicle control flow to show the effect in the case of an attack.   ). An SDN controller manages the forwarding. Besides the original CAN network of the production car, we introduce ECUs on Ethernet for diagnostics and external connectivity.

A. Realistic In-Vehicle Network
We generate three different network configurations matching our separation concepts and follow the communication matrix of our original production vehicle within the network topology. The messages are played back from recorded CAN traces of the car. In one configuration, ZCs embed CAN messages fully exposed on layer 2 to enable separation by messages. The other two configurations embed the CAN message in a SOME/IP tunnel and encode the topic or domain identifier in the multicast IP, enabling separation by topic or domain. The receiving ZC transforms the packets back to CAN frames and forwards them to the CAN buses where the destinations are located.

B. Impact of Control Flow Separation
The focus of our analysis are the CAN Control Flows (CFs) that traverse the Ethernet backbone. Therefore, we do not consider local CFs, for which the sender and all receivers are located within the same zone. In total there are 242 different CFs forwarded via the software-defined Ethernet backbone. Table I shows the generated Network Flows (NFs) for each separation concept in relation to the transported CFs. As expected, the message separation generates 242 NFs, one for each CF. Separation by domain generates 19 NFs, one tunnel for each sender and domain. All of these NFs carry multiple CFs. The topic separation generates 102 NFs, one tunnel for each sender and topic. 38 of these NFs carry multiple CFs. This means that 74 of the topics contain only one CF and therefore behave exactly like separation by message. The table also shows the minimum, maximum and average number of CFs that are sent via one NF. There is always one CF per NF using message separation. For domain separation, there is a minimum of 5, average of 13 and maximum of 37 CFs per NF. This means that there is at least one NF that carries 37 CFs which cannot be differentiated by the network. As expected, separation by topic performs somewhere in between domain and message separation. 74 NFs only carry one CF and at least one carries 17 CFs. The average is 3 CFs per tunnel. In the following analysis, separation by message can be used as a benchmark as it implements exactly the relations of the communication matrix. Figure 3 shows the share of NFs that are visible at a number of destinations not including the sender. The results for separation by topic and message look very similar. For both, a quarter of all NFs reaches one gateway, and around 40% reach fewer than three gateways. With domain separation zero NFs reach fewer than three gateways, around a third reach exactly three and nearly 70% reach all gateways in the network. This is expected because the ECUs of a domain are usually distributed throughout the vehicle and therefore most domains are present in every zone. Especially the difference in percentage of flows reaching all destinations is notable. With topic separation 18% of NFs reach all destinations, with separation by message only 11%. This indicates that the separation concept has a big influence on network overhead as CFs may be forwarded to destinations that do not need to receive them. It is also a security issue as those receivers should not be able to receive the content. Furthermore, multicast seems to be the best option to transport CFs in a zone topology as less than 30% of all CFs need to be received by only one gateway. Table II shows the communication relations between the gateways. For each destination the CFs from all other gateways and the total of all CFs to the destination are depicted. The percentages relate to the maximum CFs that are sent via the Ethernet backbone. We evaluate the separation concepts considering the following properties of CFs: • A CF is legitimate if the CAN source ECU of the CF is connected to the source gateway and at least one CAN ECU at all destination gateways is a receiver specified in the communication matrix. • A CF is received at a destination after it originated from an ECU connected to the source. • An oversupplied CF is surplus and reaches the destination although it is not needed (received − legitimate). • A CF is permitted if it could be sent by the source and would be forwarded to the destination. Even though not present in our communication matrix, these flows could be activated by malicious components. For further illustration of the table, we take a closer look at the CFs with the destination ZC FR and the source ZC FL marked as yellow line. Each gateway forwards a maximum of 242 CFs from CAN buses to other gateways via the Ethernet backbone. There are 43 CFs from ZC FR to ZC FL specified in the communication matrix according to the placement of the CAN ECUs in our topology. With separation by message, the same 43 CFs (18% of 242) are received by ZC FL from ZC FR, so the oversupply is zero.
For tunneling approaches, CFs are forwarded to gateways that are subscribed the multicast group, even though for other CFs. Hence with separation by domain, ZC FL receives 53 CFs from ZC FR, 10 of which are oversupplied CFs (4% of the maximum 242). With topic separation the oversupply is only 3 CFs. If a source sends one CF of a tunnel, the network also permits the sending of all other CFs of the NF. Separation by domain permits 232 CFs from ZC FR to ZC FR, which is 96% of all CFs. This adds 189 CFs to the 43 legitimate. Topic separation permits 115 CFs, which are 72 too many. Separation by message only permits the sending of the legitimately specified 43 CFs.
We also calculate the total amount of CFs received, oversupplied, and permitted for each destination, for example ZC FR marked in green. Since 4 sources are always considered for each destination, the maximum possible CFs to the destinations are 4 times 242, which is 968. The zone FR requires a total of 137 CFs. When separated by message it receives the same 137 CFS, 158 by topic, and 177 by domain. This results in a total of 21 CFs oversupplied to ZC FR with topic separation, and 40 with separation by domain.
For permitted flows the difference is more extreme as the hidden embeddings allow a lot more messages compared to the exposed embedding. For topics there are 342 permitted CFs which is 205 more than legitimate. For domain tunneling 647 CFs are permitted to the destination ZC FR which is 510 surplus CFs that can reach the destination ZC FR.
The totals for the whole network sum up all CFs between all nodes and are marked in red. As explained earlier, NFs are point to multipoint relations. This is why for 242 maximum CFs there are 582 legitimate CFs from all sources to all destinations. For the whole network 4840 CFs would be possible as each source could send a maximum of 242 CFs to each destination. This is also reflected by the message separation while for topic separation 708 and for domain separation 915 CFs reach the destinations. Figure 4 visualizes the shares of legitimate, oversupplied, permitted and forbidden CFs in relation to the maximum possible CFs in the three cases marked in Table II. A forbidden CF is filtered by the backbone and is not forwarded from the source to the destination. All three cases clearly show the effectiveness of the strict message separation via exposed embedding. When separated by message, the software-defined backbone only forwards the legitimate CFs and forbids any other CF. The hidden application layer embeddings oversupply and permit illegitimate CFs. This leads to fewer CFs that are forbidden, while still only CFs of the tunnels that are already in use by the sending nodes are allowed by the network. More precisely, topics can improve the separation of flows in the network. As stated earlier, we chose our topics by grouping similar messages in the communication matrix. There are some   Table II CFs we could not group into topics. This impacts the results for the separation as those CFs are perfectly separated by their own topic with only one CF.
Gateways can filter the unneeded CFs at the cost of processing power so that no unwanted message reach a CAN bus. Still, the network load on the backbone increases due to the oversupplied control traffic. In the third case, 12% of the maximum CFs from all sources to all destinations are legitimate. With separation by topic additional 3% are received at the destinations, with domain separation around 7%. Network load on the backbone increases by 57% with domain separation, and by 27% when separated by topic as compared to the legitimate CFs.
These results clearly conflict with the benefits of aggregation, which is one of the main arguments for using a hidden embedding. Above all, it is a security issue that network nodes get exposed to messages they are not prepared for. This is especially the case for HPC I which receives an oversupply of 37 CFs when separated by topic and 146 CFs when separated by domain. This is twice as many received CFs with topic separation compared to the legitimate CFs and over four times as many with domain separation. The separation by message is the only concept able to solve this problem with zero oversupplies. More fine-grained tunneling could lead to better separation. However, this approach also reduces the advantages of application layer tunneling such as easier setup with higher layer sockets, the possibility to aggregate, and fewer NFs.
From a security perspective, the CFs that a (malicious) ECU can send are even more important than the CFs it can receive. From all sources to all destinations, 31% of all CFs are allowed with topic separation and even 67% with separation by domain, while only 12% are needed. The domain separation with a total of 3232 allowed CFs on the network results in a 455% increase in permitted CFs compared to the 582 legitimate CFs on the backbone. For topic tunnels there are 1482 permitted CFs which is an increase of 155%. However, the difference is not as drastic for CFs permitted from HPC I, which in every separation concept can only send CFs of the infotainment domain to the other gateways. Still, this shows the security weakness of the tunneling approach. When a device participates in a tunnel, it can listen to all CFs of this tunnel and is permitted to send all CFs of the tunnel.
Fewer filtering of CFs eases attacks as fewer ECUs need to be compromised to gain control over the car. Even if gateways filter all unwanted and illegally sent messages it would still be possible to attack the NFs, e.g., by flooding the tunnels to delay time-critical flows. In the case of exposed embeddings, which fully isolates messages by SDN, attackers must compromise the exact sender of each CF in the Ethernet backbone to issue messages in this channel.
The presented zone topology with an enforced separation of messages by SDN is also more secure than the original network architecture of our production vehicle. In a pure CAN bus architecture, the traffic on buses cannot be controlled. All ECUs connected to a domain bus can send any CF and receive all messages on the bus. A compromised ECU can attack all other ECUs in its domain. Gateways can use the CAN IDs to filter which messages are to be forwarded to another bus, but cannot verify the correct sender of a CF. The zone topology splits the CAN domain buses so that less ECUs connected to a physical bus, which allows the zone controllers to filter messages and less ECUs are completely unprotected. If each ECU were directly connected to the zone controller, the correct sender could be verified. Combined with separation of messages by SDN, this could offer a perfect separation of CFs and thus a trustworthy communication backbone.

C. Case Study: Impact on a Critical Vehicle Control Flow
To illustrate how CF separation can reduce the attack surface of an IVN, we now pick critical CFs often used in attack scenarios from known exploitations against passenger vehicles such as [17]. We select the acceleration request as a sample CF, which we examine in two different cases. The first case assumes a compromised CAN ECU. We discover all CAN ECUs that are allowed to send the acceleration request to the original recipients. Second, an Ethernet node could be compromised. We discover which gateways can send the acceleration request to the original receivers via Ethernet.
The acceleration request is sent by the Adaptive Cruise Control (ACC) connected to ZC FL. ECUs connected to the gateways ZC FR and ZC RR require the CF. A compromised CAN ECU can be in the same or a different zone and domain from the target ECU. If the compromised ECU is connected to the same physical bus as the original source or the destination of the CF, the attack can not be prevented. This is the case for 7 CAN ECUs in our topology. If the compromised ECU is not on the same physical bus, the gateway connected to the source ECU can filter illegitimate CFs. If the compromised CAN ECU is in a different zone the CF is forwarded over the Ethernet backbone. There is only one additional ECU that can send the acceleration request with separation by message on the backbone. With separation by domain, the backbone forwards the CF from 29 additional ECUs with separation by topic 11. Still, all those would be filtered in the source and destination gateways, except the one also permitted with separation by message. This shows the impact of the zone topology. Dividing the domain buses into separate zones allows the gateways to filter messages. If all ECUs were directly connected to a ZC, it could precisely identify each sender and their permitted CFs.
In case of a compromised gateway, the CFs can only be protected by the Ethernet backbone. With separation by message the acceleration request is only received at the two gateways ZC FR and ZC RR which require the information. Both hidden embeddings lead to oversupply of this critical CF. With separation by topic the CF is additionally forwarded to HPC I, with separation by domain to ZC RL and HPC I. Only the original sender (ZC FL) is allowed to send the acceleration request with message separation. With domain and topic separation, ZC RL and ZC FR are also allowed to send the command and it is forwarded to the three other ZCs.
The communication relations for this example show the benefits of an exposed embedding over hidden embeddings in tunneling protocols. Hidden embeddings lead to unwanted receivers of critical CFs and permit their transmission from other network participants which is a risk for safety and security. An exposed embedding enables the separation of all CFs in the network and can establish a trust zone between the gateways, so that only the original sending gateway is permitted to send the CF and it reaches only the necessary destinations. This improves network security even in the case of a compromised gateway.

V. CONCLUSION AND OUTLOOK
In this work, we comparatively analyzed three strategies for integrating separated control flows in a software-defined Ethernet backbone. We evaluated each separation concept in a real-world IVN, which we transformed into a modern software-defined Ethernet topology. The analysis showed that embedding of exposed control flow information into the header fields can be matched by forwarding devices and improves network security and performance. Hidden embeddings in application-layer tunneling protocols have a significant oversupply of surplus control flows which opens a security gap.
In detail, we could clearly show that exposing control flow identifiers to layer-2 packet headers allows for precise identification of each vehicle control message and protect the information with a precise access control. Furthermore, a finegrained control flow separation improves the precision in realtime configuration. In contrast, application layer encapsulation using SOME/IP obfuscates control flows for IVNs and prevents a separate management of flows at the price of network security and performance. A detailed case study confirmed that a precise and exposed control flow embedding allows for isolated communication contexts across the backbone and can establish trust zones between the gateways.
In future work, we will extend this analysis to cover a broader variety of in-vehicle communication flows and to advance the security in cars by additional network layer intelligence.