The need for deep packet inspection in automotive networks
April 06, 2018
Story
As bandwidth requirements have increased, new network standards and topologies have been implemented in the car.
Over the past ten years, the use of networking protocols has increased greatly. This has been driven in part by the rise in the number of electronic control units (ECUs) that take care of many specific functions, such as adaptive cruise control, anti-lock braking systems, and central locking functions. As bandwidth requirements have increased, new network standards and topologies have been implemented in the car. This has led to multiple technologies and standards for inter?ECU communication, including CAN, CAN-FD, FlexRay, LIN, MOST, and even others such as USB and LVDS. Sensor data sharing has been achieved by different bus networking methods in an ad-hoc manner.
In the past five years, the move to more sophisticated functions within the car, driven by advanced driver assistance systems (ADAS), has stipulated higher levels of connectivity. Significantly higher throughput of data communication, with the goal to reduce latency through the network, has prompted a review of which networking approach should be employed. This has coincided with the growth of in-car infotainment systems, Wi-Fi network capability, and provisioning future ease of support for V2X systems.
Perhaps it is no surprise that Ethernet has emerged as the de-facto vehicle networking protocol for new automotive platforms. The legacy network protocols are likely to remain in use for a while, so incorporating support for these legacy network protocols within the Ethernet ecosystem is important. IEEE 1722 has specified a method of taking legacy communications such as CAN and LIN to be encapsulated within Ethernet packets, with the aim of making Ethernet the primary automotive networking method. With a proven record outside the automotive environment, Ethernet has impressive credentials and will help to simplify the complexities of automotive networking. Furthermore, wiring harnesses are among the top five most expensive and heavy components inside an automobile, so using a single well-proven network will help reduce both factors. Both 100 Mbps and 1 Gbps automotive Ethernet standards have been defined to be used with an unshielded single pair of copper cables.
The increase of Internet connectivity in the car opens up potential attack surfaces and entry points, making attention to security of paramount importance, but it also opens up the potential to provide more network functionality within the Ethernet switch by analyzing the data stream. For the embedded developer, the need to conduct real-time wire speed analysis of all incoming data without introducing any degree of latency, while using a finite amount of compute resource, can be a challenge. Achieving the necessary protection or additional functionality requires the inspection of packets using a set of pre-determined rules. This is executed based on certain data values or conditions being encountered. Examples include a host of new audio/visual applications and time critical or sensitive networking requirements.
Within a legacy Ethernet switch, decisions regarding which port a packet should be forwarded to are taken at layer 2 (L2) of the OSI networking model (Figure 1).
In Figure 1, if the source address (SA) of the incoming frame has not previously been seen, it is added to the address database along with the ingress port number of the frame. If the destination address (DA) is already in the bridge’s lookup table, then the packet is forwarded accordingly or else the frame is flooded. Over the years, the IEEE standards that govern the protocols used at L2, such as 802.1 MAC bridges, VLANs, and port-based network access control standards, have focused on the first 16 bytes of an Ethernet frame. They have evolved steadily, with recent additions including audio/video broadcast (AVB) time sensitive networking standards such as 802.1AS. In particular, the need for a deterministic network within the automotive environment is becoming necessary in order to guarantee timing and guaranteed delivery across the network. Locking all ECUs to a single Grand Master clock source and maintaining AV content quality are just two examples. More enhanced capabilities have also been introduced that facilitate inspection of OSI level 3 information, such as IPv4/IPv6 packet priority and IPv4/IPv6 snooping.
While the above techniques have initially sufficed in automotive Ethernet-based applications, there needs to be more flexibility moving forward to inspect packets in a real-time ‘wire-speed’ approach so that advanced packet classification, debug/diagnostics and security features can be implemented. The possibility of achieving deep packet inspection (DPI), however, has to be balanced with those of space-constrained and budget-sensitive automotive applications. It has not been possible in the past to achieve such wire-speed packet classification without using a number of compute intensive devices that have occupied additional board space and impacted on the bill of materials (BoM). However, new devices, such as Marvell’s Gigabit Ethernet switch, are now able to offer such capability in a compact package using a DPI engine an approach taken from the world of enterprise networking.
The DPI engine employs a technique call ternary content-addressable memory (TCAM). TCAM takes the packet data and matches its contents to a pre-defined filter to find matching occurrences. Based on the matching or non-matching outcome, the DPI engine can then determine the action to be taken. This approach provides three possibilities (thus the term ternary) for matching the binary data, where the state or each bit can be determined to be a 0, 1 or "X" don’t care. The "don’t care" rule can be extremely useful for setting up masks that allow easy checking of ranges of data. Implemented with a wide parallel array of gates situated within the bridge’s pipeline, TCAM supports wire-speed classification and modification of data across multiple ports. Depending on the implementation, TCAM can operate on a set number of bytes within the packet header and payload area. DPI can perform actions such as changing the destination port of the packet, discarding a frame, mirror a frame to another port, or change the frame or queue priority.
Let’s take a look at three automotive use cases for DPI, the first being for debug/diagnostics. Use of an Ethernet on-board diagnostic (OBD) is typically designed with a 100BASE-TX port that has a speed of 100Mbps. While this appears to be suitable for most applications, the practical reality is that contention ratios in fully utilized switch configurations are forwarding data well in excess of 100Mbps so it is not possible to mirror all frames in the switch without affecting performance of the real data flow. This leads to packets that are dropped, with the result that not all mirroring occurs. The alternative is to use DPI to identify and classify only the frames of interest (Figure 2). In this example, an issue with precision time protocol (PTP) frames, a DPI rule can be set to mirror all ports with PTP messages to the OBD port. This can be achieved by either the EtherType (0x88F7) or the MSG ID, for example. All the PTP related frames would be mirrored to the OBD port, even if the switch were operating at its maximum capacity.
Another application of DPI is for security. Identification of valid Ethernet packets can consume a large amount of compute resources for a CPU located in the data path and means that in order to achieve real-time, low latency classification, the demands on processing capabilities will be outside the size, BoM and capabilities of most automotive environments. However, the TCAM provides a means of checking that every packet entering an Ethernet switch has the correct format for the network.
In the example illustrated in Figure 3, TCAM masks are set to allow only incoming packets within a range of MAC DAs, SAs and VLAN IDs, these being, destinations of 00:01:02:XX:XX:XX (match all MAC DA addresses in the range 00:01:02:00:00:00 to 00:01:02:FF:FF:FF), source addresses of 00:11:22:XX:XX:XX (match all MAC SA addresses in the range 00:11:22:00:00:00 to 00:11:22:FF:FF:FF) and VLAN ID: 0x0XX (match all VLAN IDs in the range 0x000 to 0x0FF).
This example utilizes only the L2 information from the packet; however, depending on the TCAM implementation, L3, L4 or higher layer information can be used to form part of the TCAM match.
TCAM presents the only cost effective, low latency and low resource method of being able to check every packet that enters a switch. Packets that do not pass the above tests can be dropped or initiate another action to occur.
In the final use case example, DPI is used to perform routing decisions of encapsulated Ethernet packets. As previously mentioned, the move is to incorporate many of the different legacy automotive networking protocols, such as LIN and CAN within Ethernet, with a long term goal of reducing automotive network complexity and costs. While there are gateways that exist to perform such encapsulation, the forwarding decisions have to be made once they have been encapsulated. However, using DPI provides a method of making forwarding decisions based on the encapsulated data. The format of the packets is already defined according to IEEE1722-2016, so TCAM can be used to classify the type of packet (CAN, for example), and use the CAN_BUS_ID and CAN_IDENTIFIER to create routing actions accordingly.
Implementing TCAM-based DPI techniques within an automotive network environment opens up support for a host of new applications, standards, and functions previously not commercially viable. As the connected car becomes reality, manufacturers are being challenged to incorporate a lot more in the way of security functions while at the same time attempting to simplify the complexities of the network environment. DPI presents the opportunity to achieve both.
