Central Point Architecture in Security Devices Overview

The central point (CP) architecture has two basic flow functionalities: load balancing and traffic identification (global session matching). As described in this topic, the central point architecture is implemented either in centric mode, in which all session distribution and session matching is performed by the central point, or in mixed-mode, in which a percentage of Services Processing Unit (SPU) is dedicated to performing the central point functionality.

The central point’s main function is to delegate session processing to one of the SPUs. If the session has not yet been established, the central point selects an SPU to establish the session for the flow, based on load- balancing criteria. If the session already exists, the central point forwards packets for that flow to the SPU hosting it. It also redirects packets to the correct SPU in the event that the NPU fails to do so.

The central point maintains a global session table with information about the owner SPU of a particular session. It functions as a central repository and resource manager for the whole system.

The SRX Series Firewall type in conjunction with the Junos OS release determine which mode is supported.

Table 1 identifies the central point architecture implementation that is supported on SRX Series Firewalls for various releases.

The central point forwards a packet to its Services Processing Unit (SPU) upon session matching, or distributes traffic to an SPU for security processing if the packet does not match any existing session. The central point architecture is implemented in CP centric mode, in which all session distribution and session matching is performed by the CP or in combo mode

On some SRX Series Firewalls, an entire SPU cannot be dedicated for central point functionality, but a certain percentage of the SPU is automatically allocated for central point functionality and the rest is allocated for normal flow processing. When an SPU performs the function of central point as well as normal flow processing, it is said to be in combination, or mixed, mode.

The percentage of SPU dedicated to the central point functionality depends on the number of SPUs in the device. Based on the number of SPUs, there are three modes available on the SRX Series Firewalls— small central point, medium central point, and large central point.

In small central point mode, a small percentage of an SPU is dedicated to central point functionality and the rest is dedicated to the normal flow processing. In medium central point mode, an SPU is almost equally shared for central point functionality and normal flow processing. In large central point mode, an entire SPU is dedicated to central point functionality. In mixed-mode, the central point and SPU share the same load-balancing thread (LBT) and packet-ordering thread (POT) infrastructure.

This topic includes the following sections:

• Load Distribution in mixed Mode
• Sharing Processing Power and Memory in mixed Mode

Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, on SRX5000 line devices, the central point architecture is enhanced to handle higher connections per second (cps). The new central point architecture prevents data packets from going through the central point by off-loading session management functionalists to the Services Processing Unit (SPU). Therefore, data packets are directly forwarded from the network processing unit to the SPU instead of going through the central point.

The central point architecture is divided into two modules, the application central point and the distributed central point. The application central point is responsible for global resource management and loading balancing, while the distributed central point is responsible for traffic identification (global session matching). The application central point functionality runs on the dedicated central point SPU, while the distributed central point functionality is distributed to the rest of the SPUs. Now the central point sessions are no longer on the dedicated central point SPU, but with distributed central point on other flow SPUs.

The central point architecture, which is supported on the SRX5400, SRX5600, and SRX5800 devices, is enhanced to address the GTP-C message rate-limiting to protect gateway GPRS support node (GGSN) from GTP-C message flood, to prevent GTP-C packet drop issues during SGSN handover, and to distribute GTP-U traffic handled by a GGSN and SGSN pair on all SPUs by switching to tunnel endpoint identifier (TEID)-based hash distribution. Use the enable-gtpu-distribution command to enable or disable GTP-U session distribution. By default, the enable-gtpu-distribution command is disabled.

Connection-tag to flow session tuple is introduced to resolve GTP/SCTP load balance issue. All session including Distributed CP (DCP) session and SPU session are modified to accommodate connection-tag. The session creation have following tuple: src-ip, dst-ip, src-port, dst-port, protocol, session-token and connection tag.

The GTP ALG requires GTP-C sessions to be fixed by hashing GGSN IP addresses. The GTP ALG deny GTP-C session creation if the first packet is of uncertain direction, which will cause packet drop. To prevent the GTP-C packets from being dropped, a new flow session is created and the GTP-C traffic is allowed to pass even if the GGSN or SGSN direction is not determined. Later, the GGSN IP is determined using the correct SPU to create the flow session and age out the old session. The intermittent packets hitting the old session will be forwarded to the new SPU and be processed on the new session.

To handle load-balancing issues, tag-based hash distribution is used to ensure even distribution of GTP-U/SCTP traffic among all SPUs. A 32-bit connection tag is introduced that uniquely identifies the GTP-U and the SCTP sessions. The connection tag for GTP-U is the TEID and for SCTP is the vTag. The default connection-tag is 0. The connection tag remains 0 if it is not used by the sessions. Flow will determine connection tag for GTP-U/SCTP sessions and distribute them by hashing connection tag.

A SCTP association is a connection between two SCTP endpoints. Each SCTP endpoint identifies the association with a tag. During association setup (4-way handshakes), two SCTP endpoints exchange their own tags for packet receiving. During 4-way handshake, the receiver of INIT/INIT-ACK records the value of itag, and places into the vtag field of every SCTP packet that transmit within this association. Then the peer uses the vtag to validate the sender of this packet.

Flow sessions created after CP-Lite as follows:

SPU is selected by hash(tag), the Client to Server traffic is handled on hash (tagB) SPU then forwarded to hash (tagA) SPU. Server to Client traffic is handled on hash (tagA) SPU directly.

1. After receive INIT packet, on hash (tagA) SPU:

   DCP-session A1: client=> server, SCTP, Conn ID: 0x0;

   Session A1: client=> server, SCTP, Conn ID: 0x0;

   On hash (tagB) SPU: no session.

2. After receive INIT-ACK packet, on hash (tagA) SPU:

   DCP-session A1: client=> server, SCTP, Conn ID: 0x0;

   DCP-session A2: server => client, SCTP, Conn ID: tagA;

   Session A1: client=> server, SCTP, Conn ID: 0x0;

   Session A2: server => client, SCTP, Conn ID: tagA;

   On hash (tagB) SPU: no session.

3. After receive COOKIE-ECHO packet, on hash (tagA) SPU:

   DCP-session A1: client=> server, SCTP, Conn ID: 0x0;

   DCP-session A2: server => client, SCTP, Conn ID: tagA;

   Session A1: client=> server, SCTP, Conn ID: 0x0;

   Session A2: server => client, SCTP, Conn ID: tagA;

   Session A3: client=> server, SCTP, Conn ID: tagB;

   On hash (tagB) SPU:

   DCP-session: client => server, SCTP, Conn ID: tag B

4. After receive COOKIE-ACK packet, flow sessions have no change.

5. After handshake succeeds, HEARBEAT will be send on all paths.