Upload
phungdung
View
217
Download
1
Embed Size (px)
Citation preview
Benefits of Deep Packet Inspection Techniques for Advanced Automotive Ethernet Architectures
Christopher Mash [email protected]
Automotive Applications and System Architecture
September 2016
Agenda
How do Ethernet Bridges Work?
Additional Flexibility Already Required
Introducing the TCAM
Application Examples
Summary
How do Ethernet Bridges Work?
• Frames are ‘switched’ based on the MAC
Destination Address(DA) of the frame
L2 - MAC
MAC DA MAC SA
• Ethernet bridges traditionally
operate at the Layer 2 of the
OSI networking model
Adding L2 Features
• Lots of additional features have been added over the years via
IEEE802.1 and more are continually being added:
– 802.1D – MAC Bridges
– 802.1Q – Virtual LAN’s
– 802.1X – Port Based Network Access control
– … (> 60 projects and increasing)
– AVB/TSN Specific
802.1AS - Timing and Synchronization for Time-Sensitive Applications (PTP)
802.1Qat – Stream Reservation Protocol (SRP)
802.1Qav – Forwarding and queuing enhancements
802.1Qbv – Time Aware Shaper (TAS)
… (> 10 projects and increasing)
VLAN ID = 0x017
Priority = 4
Advanced Bridges - L3 Features
• Advanced Bridges can also inspect some L3 information such as:
– IPv4 / IPv6 packet priority
– IGMP Multicast Snooping (IPv4)
– MLD Multicast Snooping (IPv6)
– …
• All these features along with:
– Ingress rate limiting
– Egress rate shaping
– Port mirroring
– Port isolation
– …
• Provide a large tool box to work with when designing automotive
networks
Agenda
How do Ethernet Bridges Work?
Additional Flexibility Already Required
Introducing the TCAM
Application Examples
Summary
Additional Flexibility Already Required
• For the first Ethernet implementations in Automotive, these features
seemed enough
• However, we now know that greater flexibility is already needed to
support:
– Advanced debug & diagnostics
– Advanced classification
– Enhanced security
– Future / custom protocols
– Many more…
• What is really needed is a programmable advanced classification
engine to provide flexibility for advanced features
– Luckily this problem was solved in the Enterprise space a long time ago…
Agenda
How do Ethernet Bridges Work?
Additional Flexibility Already Required
Introducing the TCAM
Application Examples
Summary
Introducing the TCAM
• Stands for Ternary Content-Addressable Memory (TCAM)
– Ternary: Data to match can be 0, 1 or don’t care (3 States)
– Content-Addressable Memory: The memory is accessed by the Data not an
Address
– Implemented as a wide parallel array of gates operating within the Bridge pipeline
• TCAM’s can support wire speed classification on multiple ports at
the same time
– On the fly frame classification and modification at wire speed
• Based on the implementation, the TCAM can act on a set number of
bytes within the packet header to provide a ‘match’ or ‘hit’
• Different TCAM designs implement the matching differently:
– Basic Implementation: Certain pre-defined Bytes can be selected
– Advanced Implementation: Every bit can be matched to 0 or 1, or don’t care
TCAM – Matching
• With the example below a 42-Byte rule would be enough to match
down to the IPv4 UDP/TCP destination port of the L4 header
• Advanced TCAM implementations support even greater rule sizes
– Able to create matches all the way down to Application Layer (OSI – Layer 7)
L4 Destination Port: 17000 (0x4268)
L4 Source Port: 16384 (0x4000)
IP Destination Address: 192.168.0.1
IP Source Address: 192.168.0.100
TCAM – Actions
• After a TCAM ‘match’ occurs then an ‘action’ is performed
• The actions available depend on the bridge & TCAM implementation
• Examples of some standard actions:
– Override destination port – i.e., what port(s) the frame is mapped to
– Override VLAN Identifier (VID)
– Change frame or queue priority
– Trap, mirror or drop frame
– Add or remove the frame’s VLAN ID
– Increment a counter
• Some possible advanced features:
– Treat frame as a management protocol frame
– Provide per flow or per class rate limiting and policing
– Change load balancing on trunked ports
– …
Agenda
How do Ethernet Bridges Work?
Additional Flexibility Already Required
Introducing the TCAM
Application Examples
Summary
Security
• Traditionally the CPUs present in the network can be used for
security to check the validity of the Ethernet packets
– If the CPU is located in the data path, a lot of resources and processing power are
required
– Imagine when we move to multiple 1000BASE-T1 switches with higher speed
uplinks, in this use case a very powerful enterprise class network processor would
be required!
– Cost of implementation and required CPU power mean this is not currently
practical
• Solution – Use TCAM to classify all frames on all ports
Security
• Wire speed classification on all ports simultaneously is possible with
the TCAM
• The TCAM can be used to check every packet that enters the switch
has the correct format for the network
• Packets that do not meet the network format can either be dropped,
trapped to the CPU or any other TCAM ‘Action’ can occur
• Example: Allow only accepted range of MAC DA’s, SA’s & VLAN ID
– DA: 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)
– SA: 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)
– VLAN ID: 0x0XX (Match all VLAN ID’s in the range 0x000 to 0x0FF)
xx xx xx xx xx xx x xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
Flow Based Rate Limiting
• Ingress rate limiting classifies traffic and limits the amount of data
allowed to flow into the Bridge based on data rate, priority, …
• Works well when all nodes in the network follow the rules
• What about when a node malfunctions or an unknown device floods
the network with high priority management traffic?
• This can lead to a Denial of Service attack (DoS) in the network
– Local CPUs are flooded with management data and overloaded processing all
received packets
– Delay’s processing of time sensitive protocol’s
– Bridge internal buffers can fill up and result in the Bridge dropping ‘Real’
management frames
• Solution – Use TCAM to classify and protect genuine management
flows
Flow Based Rate Limiting Example
• Create TCAM entry to ‘Match’ genuine known management flows
– Many options available, MAC DA, VLAN ID, Multiple VLAN tags, Protocol, etc
– Action: Do not rate limit this traffic on ingress to the switch
• Additional TCAM entry to ‘Match’ all other non genuine management
data using same priority, traffic type, etc
– Action: Rate limit the data on ingress to the switch
• These two TCAM entries and associated ‘Actions’ protect genuine
management traffic and prevent DoS attack in the Automotive
network
On Board Diagnostics – DoIP
• Current implementations of OBD use multi-pair Ethernet in the form
of 100BASE-TX routed from the Gateway to external connector
• This connection provides easy access to the automotive network
however, can be used as primary attack vector for:
– Network snooping, Denial of Service attack (DoS), DHCP attack, etc
• Primary protocol for this interface is Diagnostics over IP (DoIP) -
specified as ISO 13400 and uses both UDP (e.g. Discovery) and
TCP (e.g. Diagnostics) protocols over IPv4 or IPv6
• Gateway is required to check all packets to ensure they meet the
network requirements, however:
– CPU intensive, especially during FW download with high data rate
– Susceptible to DoS, DHCP attacks, etc
• Solution – Use TCAM to classify all OBD traffic to ensure meets
valid DoIP profile
On Board Diagnostics – DoIP Example
• Create TCAM entry to ‘Match’ genuine known DoIP flows
– Many options available, IPv4 or IPv6, MAC DA & SA, Range of UDP/TCP ports, etc
– Action: Forward traffic from OBD port to Gateway CPU
• All traffic that does not meet the rule above is discarded
• These TCAM entries and associated ‘Actions’ protect genuine DoIP
sessions over the OBD port and prevent DoS, DHCP, etc attacks
Debug/Diagnostics
• OBD Ethernet ports are currently limited to 100 Mbps
– This sounds like a lot but lets investigate a typical a 6 or 7 port Switch:
– 5 x 100BASE-T1 ports :500 Mbps
– 1 x 1000 Mbps MAC ports :1000 Mbps
– Maximum Bandwidth :1500 Mbps (Full-Duplex)
• OBD port configured to ’mirror’ port data
– Theoretical max bandwidth assuming
mirroring ingress and egress traffic for all
ports will be 3000 Mbps
– 30:1 data contention ratio
– When switches are loaded and internal
buffers are full, they will either drop packets
destined for mirroring or drop packets at the
regular network ports
– Advanced bridge designs ensure that regular
network ports continue to operate while
packets are dropped at the mirror port
Debug/Diagnostics Example
• Now, imagine you are trying to debug an issue that occurs
occasionally
• 1000BASE-T1 is now here, what about when all ports on the switch
support 1Gpbs and greater?
• Solution – Use TCAM to classify only the frames of interest
– The probability you will capture the frames of
interest during sustained data transfer or large
bursts is extremely unlikely
– Debug will be extremely difficult
– For example: Issues with PTP in the network
– Create TCAM rule to mirror all ports ingress/egress
PTP messages to the OBD port
– Can use EtherType (0x88F7), MSG ID, version, etc
– Will mirror all PTP frames even under maximum switch
load
Encapsulated Data
• There are already multiple different networking topologies in the car
– LIN
– CAN
– FlexRay
– …
• Long term goal of automotive Ethernet is to reduce the complexity of
the network
• Gateway designs exist already to encapsulate legacy traffic into
Ethernet
– Gateway has to determine how to encapsulate and forward
around the network
– Not flexible and forwarding decisions have to be determined
at outset
• IEEE 1722 has defined encapsulated packet
formats for the above technologies and is covered
in the recently released IEEE 1722-2016
Encapsulated Data Example
• Solution – Use TCAM to make forwarding decisions based on
encapsulated data payload
– Use formats defined in IEEE 1722-2016 or any other format already in use
– Use TCAM to classify the packet as ‘CAN’ data and use ‘CAN_BUS_ID’ or
‘CAN_IDENTIFIER’ to create the ‘Match’
– Now able to use any TCAM ‘Action’ to modify the packet flow, VLAN ID, Priority, etc
Extracts from IEEE 1722-2016
Additional Examples
• This presentation has covered just a few applications for the TCAM,
but many more applications exist:
• Use TCAM to pre-classify and modify frames towards the CPU
– Optimizes the data to reduce the CPU workload in classifying the packets
– Reduce the required CPU complexity and cost
• Support future TSN/Avnu/… protocols that are not yet completed
– Use TCAM to classify packet according to new protocol definition
– Use available Actions to support protocol handling
– Test future protocols in current network topologies
• Create custom user or network-specific protocols
– TCAM provides the flexibility to create any protocol and classify @ wire speed
• And many, many more…
– Possible options are limited only by your imagination
Agenda
How do Ethernet Bridges Work?
Additional Flexibility Already Required
Introducing the TCAM
Application Examples
Summary
Summary
• TCAM - wire speed classification on all ports at the same time
– Create rule to determine what data to ‘Match’
– Determine what ‘Actions’ to take when ‘Match’ occurs
– Provides maximum system architecture flexibility
• TCAM Match + Action =
Advanced classification
Enhanced security
DoS prevention
DoIP protection
Advanced debug & diagnostics
Forward packets based on LIN/CAN/… data
Reduce design complexity
Less CPU power required / lower BOM
Future proof network / support new protocols
Create custom protocols
Summary
• For more information on the TCAM and application examples please
visit the Marvell booth
• In addition, see the industry’s first:
• 1000BASE-T1 PHYs
• 1000BASE-T1 Bridge
• Deep Packet Inspection using the TCAM
provides maximum flexibility during
automotive design implementation to solve
complex problems
Thank You