SCTP Overview

https://www.juniper.net/documentation/us/en/software/junos/gtp-sctp/topics/topic-map/security-gprs-sctp.htmlhttps://www.juniper.net/documentation/us/en/software/junos/gtp-sctp/topics/topic-map/security-gprs-sctp.html

Stream Control Transmission Protocol (SCTP) is a transport-layer protocol that ensures reliable, in-sequence transport of data. SCTP provides multihoming support where one or both endpoints of a connection can consist of more than one IP address. This enables transparent failover between redundant network paths.

Understanding Stream Control Transmission Protocol 

Stream Control Transmission Protocol (SCTP) is an IP Transport Layer protocol. SCTP exists at an equivalent level with User Datagram Protocol (UDP) and Transmission Control Protocol (TCP), which provides transport layer functions to many Internet applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP and supports data transfer across the network in single IP or multi-IP cases.

SCTP can transport signaling messages to and from Signaling System 7 (SS7) for 3G mobile networks through M3UA, M2UA, or SUA. SCTP is a packet-based transport protocol. SCTP provide reliable and secure transport, minimized end-to-end delay, short failover time in case of network failures and both sequence and no-sequence transport.

SCTP is optimized to:

• Avoid the multithread infrastructure problems, when the traffic is high

• Improve the SCTP association searching rate (association lookup process speed is increased) by SCTP hash table optimization on the SPU

• Improve FSM for retransmission cases

Starting in Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, the SCTP module inspects IPv4 and IPv6 traffic and checks all segments of the SCTP packet. (In previous releases the module inspected only IPv4 traffic and checked only the first segment of the SCTP packet.) The packet is then permitted or dropped based on the policy. For IPv6 traffic, the SCTP module inspects every extension header until it finds the SCTP header, and then only the SCTP header is processed and all the other headers are ignored.

SCTP is used for applications where monitoring and detection of loss of session is required. The SCTP path or session failure detection mechanism, for example, the heartbeat, monitors the connectivity of the session.

Figure 1 illustrates the SCTP 4-way handshake and TCP 3-way handshake.

Figure 1: SCTP 4-way Handshake and TCP 3-way Handshake

• SCTP Services
• SCTP Limitations and Constraints
• SCTP Features Overview
• Understanding Central Point Architecture Support for SCTP

SCTP Services

SCTP provides the following services:

• Aggregate Server Access Protocol (ASAP)

• Bearer-independent Call Control (BICC)

• Direct Data Placement Segment chunk (DDP-segment)

• Direct Data Placement Stream session control (DDP-stream)

• Diameter in a DTLS/SCTP DATA chunk (Diameter-DTLS)

• Diameter in a SCTP DATA chunk (Diameter-SCTP)

• DPNSS/DASS 2 extensions to IUA Protocol (DUA)

• Endpoint Handlescape Redundancy Protocol (ENRP)

• H.248 Protocol (H248)

• H.323 Protocol (H323)

• ISDN User Adaptation Layer (IUA)

• MTP2 User Peer-to-Peer Adaptation Layer (M2PA)

• MTP2 User Adaptation Layer (M2UA)

• MTP3 User Adaptation Layer (M3UA)

• Other unspecified-configured SCTP payload protocols (Others)

• Q.IPC

• Reserved

• S1 Application Protocol (S1AP)

• Simple Middlebox Configuration (SIMCO)

• SCCP User Adaptation Layer (SUA)

• Transport Adapter Layer Interface (TALI)

• V5.2 User Adaptation Layer (V5UA)

• X2 Application Protocol (X2AP)

SCTP Limitations and Constraints

SCTP has the following limitations and constraints:

• IP Addresses

  • A maximum of eight source IP addresses and eight destination IP addresses are allowed in an SCTP communication.

  • Only static IP NAT is supported; the interface packets (from one side: client or server) coming in must belong to the same zone.

• Policies

  • Dynamic policy is not supported. You must configure all policies for SCTP sessions.

  • When policies are deleted, the related sessions and associations are cleared.

  • You configure one policy to permit SCTP traffic from all client IPs to all server IPs, and another policy to permit SCTP traffic from server IPs to client IPs. If one policy has an SCTP profile, then the same SCTP profile is needed for the reverse policy.

  • If you configure different policies for each session belonging to one association, there will be multiple policies related to one association, and the SCTP packet management (drop, rate-limit, and so on) uses the profile attached to the handling SCTP session's policy.

  • The applications used in the security policies to permit the SCTP ALG traffic cannot be configured using the application-protocol ignore option. This condition is applicable even if the SCTP ALG inspection is not configured.

• SCTP enable/disable is controlled by whether there is a SCTP profile configured.

  • If no profile is attached to a policy, SCTP packets are forwarded without inspection.

  • If a profile with the nat-only option is attached to a policy, then only NAT translation is done on the SCTP packets matching the policy. If a profile does not have the nat-only option set, then both NAT translation and SCTP inspection are done on each SCTP packet matching the policy.

  • If you disable SCTP, all associations are deleted, and subsequent SCTP packets are passed or dropped according to the policy.

  • If you enable SCTP, all existing SCTP sessions must be cleared or the traffic matching old sessions will be forwarded without any inspection from the SCTP module.

    If you want to enable SCTP again, all the running SCTP communications will be dropped, because no associations exist. New SCTP communications can establish an association and perform the inspections.

    NOTE: 

    Clear old SCTP sessions when SCTP is reenabled; doing this will avoid any impact caused by the old SCTP sessions on the new SCTP communications.

  • If you add an SCTP profile to an existing policy, you must do one of the following: clear related sessions or remove the old policy and create a new policy.

  • If you change the timeout value in the SCTP profile, the configured handshake and the timeout value in existing associations will not change.

• SCTP Rate Limiting

  • Any change in the rate-limiting configuration will not affect the subsequent traffic of existing associations. It will apply to the newly established associations.

  • The supported protocol decimal value is from 0 to 63. This value includes 48 IANA assigned protocols and 16 unassigned protocols.

  • A maximum of 80 addresses are rate limited in one profile.

  • A maximum of 10 protocols are rate limited for one address in one profile.

  • The supported rate limit value is from 1 to 12000.

• SCTP Payload Protocol Blocking

  • Any change in the protocol-blocking configuration immediately impacts the subsequent traffic of existing associations.

  • The supported protocol decimal value is from 0 to 63. This value includes 48 IANA assigned protocols and 16 unassigned protocols.

• An SCTP endpoint can be a multihomed host with either all IPv4 addresses or all IPv6 addresses. An SCTP endpoint also supports NAT-PT in two directions, from an IPv4 address format to an IPv6 address format, and vice versa. SCTP module does not support IPv4 or IPv6 mixed-up multihoming and IPv4 or IPv6 mixed-up NAT-PT.

• For static NAT to work, the interfaces packets (from one side: client or server side) coming in must belong to the same zone.

• For multihome cases, only IPv4 address parameter or IPv6 address parameter in INIT or INI-ACK is supported.

• Only static NAT is supported for SCTP.

• Only established SCTP associations are synchronized to peer sessions.

• SCTP sessions are not deleted with associations; they time out in 30 minutes, which is the default value. The timeout value is configurable and can be changed.

• If the 4-way handshake process is not handled on one node, and is handled instead on two nodes (for example, two sessions on two nodes in active/active mode) or if the cluster is in failover before the 4-way handshake is completed, the association will not be established successfully.

• One SPU supports a maximum of 20,000 associations and a maximum of 1,280,000 SCTP sessions.

  In some cases, the associations might not be distributed to SPUs very evenly because the ports' hash result on the central point is uneven. For example, this event can occur when only two peers of ports are used, and one peer has 100 associations, but another peer has only one association. In this case, the associations cannot be distributed evenly on the firewall with more than one SPU.

• Unified in-service software upgrade (ISSU) to earlier Junos OS releases is not supported.

• The M3UA/SCCP message parsing is checked , but the M3UA/SCCP stateful inspection is not checked.

• Only ITU-T Rec. Q.711-Q.714 (07/96) standard is supported. ANSI, ETSI, China, and other standards are not supported.

• Only RFC 4960 is supported.

• VPN session affinity does not support GPRS tunneling protocol (GTP) and Stream Control Transmission Protocol (SCTP).

SCTP Features Overview

The following are the important features of SCTP:

• Multihoming support where one or both endpoints of a connection can consist of more than one IP address. This enables transparent failover between redundant network paths.

• Delivery of data in chunks within an independent stream eliminates unnecessary head-of-line blocking.

• Path selection and monitoring functionality to select a primary data transmission path and test the connectivity of the transmission path.

• Validation and acknowledgment mechanisms protect against flooding attacks and provide notification of duplicated or missing data chunks.

• Improved error detection suitable for jumbo Ethernet frames.

Understanding Central Point Architecture Support for SCTP

A Stream Control Transmission Protocol (SCTP) association is a connection between two SCTP endpoints. Each SCTP endpoint identifies the association with a tag. During an SCTP association setup, two SCTP endpoints exchange their own tags for receiving packets. During the exchange of packets between two SCTP endpoints, both the source address and the destination address can change in the association life cycle.

Prior to Junos OS Release 15.1X49-D40, all sessions of a given SCTP association are hashed to the same Services Processing Unit (SPU) by the fixed per-association SCTP port pair. However, in some cases, multiple SCTP associations share the same port pair, resulting in a bad load-balancing situation with all traffic being handled by a single SPU. Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, to handle the load-balancing issue, tag-based hash distribution is used to ensure even distribution of SCTP traffic from different associations among all SPUs. A 32-bit connection tag is introduced that uniquely identifies the SCTP sessions. The connection tag for SCTP is the vTag and the connection ID remains 0 if the connection tag is not used by the sessions.

The SCTP flow session utilizes a connection tag to more finely distribute SCTP traffic across SPUs on SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices that support the SCTP ALG. The connection tag is decoded from the SCTP vtag. A separate SCTP session will be created for each of the first three packets—that is, one session for INIT, INIT-ACK, and COOKIE-ECHO, respectively. Because, the reverse-direction traffic has its own session, the session can no longer match the existing forward-direction session and pass through automatically. Therefore, similar to the forward-direction policy, an explicit policy is needed for approving the reverse-direction SCTP traffic. In this scenario, the SCTP flow session requires a bidirectional policy configuration to be established for even a basic connection.

SEE ALSO

• Understanding Enhancements to Central Point Architecture for the SRX5000 Line

SCTP Packet Structure Overview

An SCTP packet consists of the following sections:

• Common Header Section

• Data Chunk Section

Figure 2 illustrates the structure of the SCTP packet.

Figure 2: SCTP Packet Structure

• Common Header Section
• Data Chunk Section

Common Header Section

All SCTP packets require a common header section. This section occupies the first 12 bytes of the packet. Table 1 describes the fields in the common header section:

Table 1: Common Header Fields

Field	Description
Source port number	Identifies the sending port.
Destination port number	Identifies the receiving port. The hosts use the destination port number to route the packet to the appropriate destination or an application.
Verification tag	Distinguishes stale packets from a previous connection. This is a 32-bit random value created during initialization.
Checksum	Uses the cyclic redundancy check (CRC32) algorithm to detect errors that might have been introduced during data transmission.

Data Chunk Section

Data chunk section—This section occupies the remaining portion of the packet. Table 2 describes the fields in the data chunk section:

Table 2: Data Chunk Fields

Field	Description
Chunk Type	Identifies the contents of the chunk value field. This is 1- byte long.
Chunk Flags	Consists of 8 flag-bits whose definition varies with the chunk type. The default value is zero. This indicates that no application identifier is specified by the upper layer for the data.
Chunk Length	Specifies the total length of the chunk in bytes. This field is 2 - bytes long. If the chunk does not form a multiple of 4 bytes (that is, the length is not a multiple of 4) it is implicitly padded with zeros which are not included in the chunk length.
Chunk Value	A general purpose data field.

The resource manager (RM) allows 8 source IP addresses and 8 destination IP addresses during an SCTP communication.

Understanding SCTP Multihoming

A Stream Control Transmission Protocol (SCTP) endpoint can be a multihomed host with either all IPv4 addresses or all IPv6 addresses. In Figure 3, endpoint A is connected to an SRX Series device with two IPv4 addresses, and endpoint B is connected to an SRX Series device with two IPv4 addresses. Therefore, endpoint A and endpoint B can set up an association using four different pairs of IP addresses, resulting in four valid paths for communication.

Figure 3: SCTP Multihoming with Two IPv4 Endpoints

In Figure 4, endpoint A is connected to an SRX Series device with two IPv6 addresses, and endpoint B is connected to an SRX Series device with two IPv6 addresses. Therefore, endpoint A and endpoint B can set up an association using four different pairs of IP addresses, resulting in four valid paths for communication.

Figure 4: SCTP Multihoming with Two IPv6 Endpoints

Understanding SCTP Multichunk Inspection

The Stream Control Transmission Protocol (SCTP) firewall checks all chunks in a message and then permits or drops the packet based on the policy. Use the set security gprs sctp multichunk-inspection enable command to enable SCTP multichunk inspection to check all chunks in a message. Use the delete security gprs sctp multichunk-inspection enable or set security gprs sctp multichunk-inspection disable command to disable SCTP multichunk inspection to check only the first chunk.

After enabling SCTP multichunk inspection, the SCTP firewall checks all chunks in a message and permits or drops the packet. The SCTP firewall drops the packet in the following cases:

• The layout of the SCTP chunks do not follow RFC 4960.

• A control chunk cannot pass the inspection of the SCTP finite state machine (FSM) or sanity checks.

• A data chunk is not allowed to pass the SCTP profile because of the SCTP FSM or sanity checks.

• A data chunk is not allowed to pass through the SCTP profile because of protocol blocking or rate limiting. The SCTP firewall resets this chunk to a null protocol data unit (PDU) and continues to check the next chunk. A data chunk is set to a null PDU based on the following rules:

  • When you set the null PDU value to 0xFFFF using the set security gprs sctp nullpdu protocol ID-0xFFFF command, then the payload protocol identifier value is replaced with 0xFFFF and the user data field is not modified.

  • When you set the null PDU value to 0x0000 using the set security gprs sctp nullpdu protocol ID-0x0000 command, then the payload protocol identifier value is replaced with 0x0000 and the first four bytes of the user data field is replaced with zeroes.

  If all chunks in a packet are null PDUs, the SCTP firewall drops the packet.

Understanding SCTP Behavior in Chassis Cluster

In a chassis cluster configuration mode, the SCTP configuration and the established SCTP association is synced with the peer device. The SCTP module supports both active-active and active-passive modes.

The established SCTP association sends a creation or deletion message to the peer whenever an association is created or deleted on the active device. The secondary device adds or deletes an association respectively upon receiving the message from the established SCTP association. SCTP module then registers the corresponding callback function to receive and handle this message. There is no continuous timer sync between the two associations.

SCTP module will register a cold start sync function when a secondary device joins the cluster or reboots. The SCTP cold start function is called to sync all SCTP associations with the peer devices at the same time.

After the switchover, the established SCTP associations will remain functioning, but the associations in the progress of establishment will be lost and the establishment procedure needs to be re-initiated. It is also possible that the associations in the progress of teardown miss the ack message and leaves unestablished SCTP associations in the firewall. These associations will be cleaned up when the timer expires (5 hours by default) due to no activity in the association.

• You should configure all policies for your required SCTP sessions.For example, suppose you have endpoints A and B. Endpoint A has one SCTP association with x number of IPs (IP_a1, IP_a2, IP_a3...IP_ax). Endpoint B has one SCTP association with y number of IPs (IP_b1, IP_b2, IP_b3...IP_by.) The policy on the security device should permit all possible x*y paths in both directions.

• When an SCTP association is removed, the related SCTP sessions still exist and time out by themselves.

RELATED DOCUMENTATION

• Chassis Cluster Overview

Release History Table

Release

Description

15.1X49-D40

Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, to handle the load-balancing issue, tag-based hash distribution is used to ensure even distribution of SCTP traffic from different associations among all SPUs.

12.3X48-D10

Starting in Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, the SCTP module inspects IPv4 and IPv6 traffic and checks all segments of the SCTP packet.

arrow_backward PREVIOUSGGSN OverviewNEXT arrow_forwardSCTP Configuration