How FortiASIC processors work
As a world leader in high-performance information security solutions, Fortinet relies on FortiOS operating systems in conjunction with FortiASIC , which are a specialized chipset, processors for accelerating content analysis and processing network traffic of its own design. This article will detail the work of these processors. We will describe how they speed up the processing / analysis of packages.
FortiASIC
Most FortiGate models have specialized FortiASIC (Application Specific Integrated Circuit) hardware acceleration for processing traffic and reducing latency, which allows to unload the main processor (CPU).
- Network processors (NPs) - for processing network traffic
- Content processors (CPs) - for security functions
- System-on-a-Chip Processor (SOC2) - for collaboration of security functions and traffic processing
Fortinet shares its FortiGate line in performance Three categories:
- Entry Level (Desktop)
- Mid-Range
- High-End
. Each category uses different CPUs and FortiASIC, as well as a different number of them.
Network processors
NP network processors operate at the interface level to accelerate traffic by offloading traffic from the main processor. Modern models contain NP4 and NP6. Older FortiGate models include NP1 (also known as FortiAccel or FA2) and NP2.
Currently NP6 processors are the latest development and can offload the following traffic and services:
- IPv4 and IPv6 traffic, NAT64 and NAT46 traffic
- Link aggregation (LAG) (IEEE 802.3ad) traffic
- TCP, UDP, ICMP and SCTP
- IPsec VPN traffic, as well as IPsec encryption / decryption (including SHA2-256 and SHA 2-512)
- Unencrypted IPsec traffic
- IPS based on anomalies, checksum offload and packet fragmentation
- SIT and IPv6 Tunnelling sessions
- Multicast traffic (including Multicast inside IPsec)
- CAPWAP traffic
- Shaping traffic and priority queuing
- Syn proxying
- Traffic passing through Inter-VDOM link
- IPS
- Application Control
- CASI
- Flow-based antivirus
- Flow-based web filtering
NP does not support unloading of modified content at the application level, this means that sessions are not unloaded if the following security functions are included in the policy:
- proxy-based virus scanning
- proxy-based web filtering
- DNS filtering
- DLP
- Anti-Spam
- VoIP
- ICAP
- Web Application Firewall
- Proxy options
Content processors
CP content processors operate at the system level with tasks defined by the CPU. The new FortiGate models (2000E, 2500E, 6040E) contain CP9. Older versions are CP4, CP5, CP6, while current FortiGate models use CP8.
CP8 can offload the following tasks:
- Flow-based inspection IPS, Application Control, Cloud Access Security Inspection (CASI), Web Filtering, DLP, and Antivirus
- High performance VPN bulk data engine
- IPsec and SSL / TLS protocol processor
- DES / 3DES / AES in accordance with FIPS46-3 / FIPS81 / FIPS197
- ARC4 in compliance with RC4
- MD5 / SHA-1 / SHA256 with RFC1321 and FIPS180
- HMAC in accordance with RFC2104 / 2403/2404 and FIPS198
- Key Exchange Processor support high performance IKE and RSA computation
- Public key exponentiation engine with hardware CRT support
- Primarily checking for RSA key generation
- Handshake accelerator with automatic key material generation
- Random Number generator compliance with ANSI X9.31
- Sub public key engine (PKCE) to support up to 4096 bit operation directly
- Message authentication module offers high performance cryptographic engine for calculating SHA256 / SHA1 / MD5 of data up to 4G bytes (used by many applications)
- PCI express Gen 2 four lanes interface
- Cascade Interface for chip expansion
system-on-a-chip processor
SOC processors are used in the younger models of the Entry Level (Desktop) category. The purpose of the SoC architecture is to combine several processors in one chip, simplifying the overall hardware design. SOC combines CP, NP, RISC-based CPU processors.
Currently, SOC version 2 is relevant, which offloads the traffic described in the NP and CP section.
SOC Architecture
Offloading
The session unloading process takes place in several stages. The first packet of each new session always arrives at the CPU. If the NP supports the requested security features that need to be executed, the CPU sends an instruction to the NP that it can handle this session. All subsequent packets for the “fast path” session are redirected to NP. Finally, after the last TCP packet, “FIN” (finish) or “RST” (reset) NP returns the session to the CPU to close the session. Otherwise, if the NP does not support the requested security features that need to be processed, all packets in this session should be processed by the CPU.
Packet path in the unloaded session
Path of the first packet in the unloaded session
Path of subsequent packets in the unloaded session
FortiGate High-End models with two or more NP6s are physically connected together through an Integrated Switch Fabric (ISF), which allows communication between all interfaces and NP6 processors, bypassing the central processor. In this way, traffic is unloaded, even if the input and output ports belong to more than one NP processor.
Integrated Switch Fabric
NTurbo Acceleration
The NTurbo Acceleration Functionality offloads UTM / NGFW sessions that pass through an NP processor.
Thanks to NTurbo, a special “data channel” is created to redirect traffic from the NP to the IPS engine and vice versa. Unloading steps:
1.NP receives the packet and performs the required actions;
1.1 If the packet is encrypted, the packet is transmitted to the CP processor;
1.2 Decryption using CP;
1.3CP transfers NP data to the processor;
2. For flow-based UTM / NGFW inspection, NP creates a data channel with the IPS engine (processed by the CPU) and sends it data;
3. The IPS engine transfers the task of data inspection to the CP to speed it up;
4.CP returns data to the IPS engine;
5. The IPS engine returns NP data to the processor;
6. If the data has been decrypted, it is transmitted to the CP for encryption;
7. Encryption using CP;
8.CP transfers NP data to the processor;
9.NP processor transmits the CPU packet.
NTurbo supports NP4 and NP6.
NTurbo session with IPSA offload
IPSA acceleration
IPSA technology offloads “pattern matching” extensions for Flow-based UTM / NGFW validation, available in NTurbo and standard firewall sessions. IPSA supports CP7, CP8 and CP9.
IPsec Encryption / Decryption
If the IPsec tunnel uses encryption and hashing algorithms supported by the NP network processor, IPsec user data processing can be offloaded to improve performance. In this case, the NP will only decrypt the traffic, and the CP will encrypt.
IPsec Encryption / Decryption
Accelerated Flow-based and Proxy-based Inspection with CP
The Flow-based UTM / NGFW inspection detects and blocks real-time security threats by fetching packets in a session using a single-pass architecture that includes Direct Filter Approach (DFA) pattern matching to identify possible attacks or threats.
Before checking, the IPS engine can be applied using a number of decoders to determine the appropriate security modules that will be applied depending on the packet protocol and policy settings. In addition, SSL packets will also be decrypted. SSL decryption is offloaded and accelerated by CP8 or CP9 processors.
The application of security modules (IPS, Application Control, CASI, flow-based Web Filtering, flow-based DLP filtering) occurs simultaneously in one approach and is accelerated by CP8 and CP9 processors. CASI signatures are used in the Application Control part of verification. Flow-based Antivirus caches files during protocol decoding, and then scans them. If it was an SSL packet, at the end of the check it is encrypted and, accordingly, CP8 and CP9 processors accelerate this process.
Flow-based inspection
steps The proxy-based UTM / NGFW inspection extracts and caches files for further verification.
Initially, packets get into the IPS engine and undergo flow-based inspection with security functions that work only in this mode (single-pass IPS, Application Control and CASI) and, accordingly, traffic is accelerated using CP8 and CP9. After that, the packets go to FortiOS Proxy-server to check the security function in proxy-based mode. First, the proxy detects SSL traffic. SSL packets will be decrypted using CP8 or CP9 and sent again to the IPS engine for re-checking the flow-based security functions (single-pass IPS, Application Control and CASI) of already decrypted traffic. Then the traffic gets to the proxy-server, where proxy-based security functions are applied. The inspection takes place in the following order:
• VoIP inspection
• DLP
• AntiSpam
• Web Filtering
• Antivirus
• ICAP
After checking the decryption, SSL traffic is encrypted. If no threat is found, the proxy server transfers the file to the destination. If a threat is found, the proxy server can block the file and in response send a message about the reason for the block.
Proxy-based inspection steps
FortiASIC
Most FortiGate models have specialized FortiASIC (Application Specific Integrated Circuit) hardware acceleration for processing traffic and reducing latency, which allows to unload the main processor (CPU).
- Network processors (NPs) - for processing network traffic
- Content processors (CPs) - for security functions
- System-on-a-Chip Processor (SOC2) - for collaboration of security functions and traffic processing
Fortinet shares its FortiGate line in performance Three categories:
- Entry Level (Desktop)
- Mid-Range
- High-End
. Each category uses different CPUs and FortiASIC, as well as a different number of them.
Network processors
NP network processors operate at the interface level to accelerate traffic by offloading traffic from the main processor. Modern models contain NP4 and NP6. Older FortiGate models include NP1 (also known as FortiAccel or FA2) and NP2.
Currently NP6 processors are the latest development and can offload the following traffic and services:
- IPv4 and IPv6 traffic, NAT64 and NAT46 traffic
- Link aggregation (LAG) (IEEE 802.3ad) traffic
- TCP, UDP, ICMP and SCTP
- IPsec VPN traffic, as well as IPsec encryption / decryption (including SHA2-256 and SHA 2-512)
- Unencrypted IPsec traffic
- IPS based on anomalies, checksum offload and packet fragmentation
- SIT and IPv6 Tunnelling sessions
- Multicast traffic (including Multicast inside IPsec)
- CAPWAP traffic
- Shaping traffic and priority queuing
- Syn proxying
- Traffic passing through Inter-VDOM link
- IPS
- Application Control
- CASI
- Flow-based antivirus
- Flow-based web filtering
NP does not support unloading of modified content at the application level, this means that sessions are not unloaded if the following security functions are included in the policy:
- proxy-based virus scanning
- proxy-based web filtering
- DNS filtering
- DLP
- Anti-Spam
- VoIP
- ICAP
- Web Application Firewall
- Proxy options
Content processors
CP content processors operate at the system level with tasks defined by the CPU. The new FortiGate models (2000E, 2500E, 6040E) contain CP9. Older versions are CP4, CP5, CP6, while current FortiGate models use CP8.
CP8 can offload the following tasks:
- Flow-based inspection IPS, Application Control, Cloud Access Security Inspection (CASI), Web Filtering, DLP, and Antivirus
- High performance VPN bulk data engine
- IPsec and SSL / TLS protocol processor
- DES / 3DES / AES in accordance with FIPS46-3 / FIPS81 / FIPS197
- ARC4 in compliance with RC4
- MD5 / SHA-1 / SHA256 with RFC1321 and FIPS180
- HMAC in accordance with RFC2104 / 2403/2404 and FIPS198
- Key Exchange Processor support high performance IKE and RSA computation
- Public key exponentiation engine with hardware CRT support
- Primarily checking for RSA key generation
- Handshake accelerator with automatic key material generation
- Random Number generator compliance with ANSI X9.31
- Sub public key engine (PKCE) to support up to 4096 bit operation directly
- Message authentication module offers high performance cryptographic engine for calculating SHA256 / SHA1 / MD5 of data up to 4G bytes (used by many applications)
- PCI express Gen 2 four lanes interface
- Cascade Interface for chip expansion
system-on-a-chip processor
SOC processors are used in the younger models of the Entry Level (Desktop) category. The purpose of the SoC architecture is to combine several processors in one chip, simplifying the overall hardware design. SOC combines CP, NP, RISC-based CPU processors.
Currently, SOC version 2 is relevant, which offloads the traffic described in the NP and CP section.
SOC Architecture
Offloading
The session unloading process takes place in several stages. The first packet of each new session always arrives at the CPU. If the NP supports the requested security features that need to be executed, the CPU sends an instruction to the NP that it can handle this session. All subsequent packets for the “fast path” session are redirected to NP. Finally, after the last TCP packet, “FIN” (finish) or “RST” (reset) NP returns the session to the CPU to close the session. Otherwise, if the NP does not support the requested security features that need to be processed, all packets in this session should be processed by the CPU.
Packet path in the unloaded session
Path of the first packet in the unloaded session
Path of subsequent packets in the unloaded session
FortiGate High-End models with two or more NP6s are physically connected together through an Integrated Switch Fabric (ISF), which allows communication between all interfaces and NP6 processors, bypassing the central processor. In this way, traffic is unloaded, even if the input and output ports belong to more than one NP processor.
Integrated Switch Fabric
NTurbo Acceleration
The NTurbo Acceleration Functionality offloads UTM / NGFW sessions that pass through an NP processor.
Thanks to NTurbo, a special “data channel” is created to redirect traffic from the NP to the IPS engine and vice versa. Unloading steps:
1.NP receives the packet and performs the required actions;
1.1 If the packet is encrypted, the packet is transmitted to the CP processor;
1.2 Decryption using CP;
1.3CP transfers NP data to the processor;
2. For flow-based UTM / NGFW inspection, NP creates a data channel with the IPS engine (processed by the CPU) and sends it data;
3. The IPS engine transfers the task of data inspection to the CP to speed it up;
4.CP returns data to the IPS engine;
5. The IPS engine returns NP data to the processor;
6. If the data has been decrypted, it is transmitted to the CP for encryption;
7. Encryption using CP;
8.CP transfers NP data to the processor;
9.NP processor transmits the CPU packet.
NTurbo supports NP4 and NP6.
NTurbo session with IPSA offload
IPSA acceleration
IPSA technology offloads “pattern matching” extensions for Flow-based UTM / NGFW validation, available in NTurbo and standard firewall sessions. IPSA supports CP7, CP8 and CP9.
IPsec Encryption / Decryption
If the IPsec tunnel uses encryption and hashing algorithms supported by the NP network processor, IPsec user data processing can be offloaded to improve performance. In this case, the NP will only decrypt the traffic, and the CP will encrypt.
IPsec Encryption / Decryption
Accelerated Flow-based and Proxy-based Inspection with CP
The Flow-based UTM / NGFW inspection detects and blocks real-time security threats by fetching packets in a session using a single-pass architecture that includes Direct Filter Approach (DFA) pattern matching to identify possible attacks or threats.
Before checking, the IPS engine can be applied using a number of decoders to determine the appropriate security modules that will be applied depending on the packet protocol and policy settings. In addition, SSL packets will also be decrypted. SSL decryption is offloaded and accelerated by CP8 or CP9 processors.
The application of security modules (IPS, Application Control, CASI, flow-based Web Filtering, flow-based DLP filtering) occurs simultaneously in one approach and is accelerated by CP8 and CP9 processors. CASI signatures are used in the Application Control part of verification. Flow-based Antivirus caches files during protocol decoding, and then scans them. If it was an SSL packet, at the end of the check it is encrypted and, accordingly, CP8 and CP9 processors accelerate this process.
Flow-based inspection
steps The proxy-based UTM / NGFW inspection extracts and caches files for further verification.
Initially, packets get into the IPS engine and undergo flow-based inspection with security functions that work only in this mode (single-pass IPS, Application Control and CASI) and, accordingly, traffic is accelerated using CP8 and CP9. After that, the packets go to FortiOS Proxy-server to check the security function in proxy-based mode. First, the proxy detects SSL traffic. SSL packets will be decrypted using CP8 or CP9 and sent again to the IPS engine for re-checking the flow-based security functions (single-pass IPS, Application Control and CASI) of already decrypted traffic. Then the traffic gets to the proxy-server, where proxy-based security functions are applied. The inspection takes place in the following order:
• VoIP inspection
• DLP
• AntiSpam
• Web Filtering
• Antivirus
• ICAP
After checking the decryption, SSL traffic is encrypted. If no threat is found, the proxy server transfers the file to the destination. If a threat is found, the proxy server can block the file and in response send a message about the reason for the block.
Proxy-based inspection steps