SCTP Features and Architecture

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 an 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

  • Only static IP NAT is supported.

  • Interface packets (from either client or server side) must belong to the same zone.

• Policies

  • Dynamic policies are not supported; you must configure all policies for SCTP sessions.
  • When a policy is deleted, related sessions and associations are cleared.
  • One policy must permit SCTP traffic from all client IPs to all server IPs, and another must permit server-to-client SCTP traffic. If one policy includes an SCTP profile, the reverse policy must also include the same profile.

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

    If different policies are configured for sessions within one association, multiple policies may apply. Packet management actions (drop, rate-limit, etc.) use the profile attached to the policy handling the SCTP session.
  • Applications used in security policies to permit SCTP ALG traffic cannot be configured with the application-protocol ignore option, even when SCTP ALG inspection is not configured.

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

  SCTP Enable/Disable and Profile Behavior

  • SCTP enable/disable is controlled by whether an SCTP profile is attached to a policy.
  • If no profile is attached, SCTP packets are forwarded without inspection.
  • If a profile includes nat-only, only NAT translation is performed; otherwise, both NAT translation and SCTP inspection occur.
  • When SCTP is disabled, all associations are deleted; subsequent packets are passed or dropped based on policy.
  • When

    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. Clear old SCTP sessions when SCTP is reenabled; doing so will avoid any impact caused by the old SCTP sessions on the new SCTP communications.

    SCTP is enabled, existing SCTP sessions must be cleared, otherwise old sessions forward traffic without inspection. Reenabling SCTP drops all current SCTP communications; new associations can then be created with inspections.
  • If a profile is added to an existing policy, clear related sessions or remove and recreate the policy.
  • Changing timeout values in the profile does not affect timeout values of existing associations. Always clear old SCTP sessions when re-enabling SCTP to prevent impacts on new communications.

• SCTP Rate-Limiting

  • Configuration changes apply only to newly established associations.
  • Supported protocol decimal values: 0–63 (48 IANA assigned + 16 unassigned).

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

    Maximum 80 addresses rate-limited in one profile.

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

    Maximum 10 protocols rate-limited per address.
  • Rate limit range: 1–12000.

• SCTP Payload Protocol Blocking

  • Changes affect subsequent traffic of existing associations immediately.
  • Supported protocol decimal value range: 0–63.
• NAT-PT supported only for IPv4 ↔ IPv6 in both directions; mixed-up multihoming and mixed-up NAT-PT are not supported.
• Only static NAT is supported.

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

  For static NAT, packets from one direction must belong to the same zone.
• For multihoming, only IPv4 address parameters in INIT/INIT_ACK are supported.
• Only established SCTP associations are synchronized to peer sessions.
• SCTP sessions are not deleted when associations end; they time out in 30 minutes (configurable).

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

  If the 4-way handshake is split across nodes or a cluster failover occurs before completion, the association fails to establish.
• 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.

  M3UA/SCCP message parsing is supported; stateful inspection is not.
• Only ITU-T Q.711–Q.714 (07/96) standards are supported; ANSI, ETSI, China, and other variants are not.
• Only RFC 4960 is supported.

• VPN session affinity does not support GTP and SCTP.

  VPN session affinity does not support GTP or SCTP.

SCTP Features Overview

The following are the important features of SCTP:

• Multihoming support enabling failover through multiple network paths.

• Stream-based delivery of data chunks, preventing head-of-line blocking.

• Path selection and monitoring to choose and validate primary transmission paths.

• Validation and acknowledgment to guard against flooding attacks and detect missing or duplicated data.

• Enhanced error detection suitable for jumbo Ethernet frames.

Understanding Central Point Architecture Support for SCTP

An 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.

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.

Use Feature Explorer to confirm platform and release support for specific features.

Review the Platform-Specific SCTP ALG Behavior section for notes related to your platform.

SCTP Support for Virtual Routing and Forwarding (VRF)

The VRF feature allows for the management of remote IP addresses. Before initiating a new SCTP association, the SCTP client must set the socket option for the route‑table index (VRF index) if the egress interface to the SCTP server is configured inside a VRF. Otherwise, the association will not be established because the SCTP client will use the default/global routing instance for association establishment. On the SCTP server side, if the VRF‑index socket option is not set on the listening socket, association requests received on all VRFs are accepted. However, if the VRF‑index socket option is set on the listening socket, only association establishment requests arriving on that particular VRF are accepted.

The application can either set a socket option with a custom flag to provide the route‑table index to SCTP, to handle VRF‑based SCTP association, to place the association in that particular VRF, or to let the SCTP kernel to choose the VRF during association establishment. In the latter case, the kernel chooses the VRF based on the VRF in which the ingress interface is configured during the 4‑way handshake.

When a SCTP association is established over a VRF instance, the kernel must take into account an additional parameter, the unique VRF ID, when looking up unique associations by using the existing 4-tuple used in SCTP (source IP, source port, destination IP, and destination port).

• Inbound SCTP packets over VRF:

  When a SCTP packet arrives on an ingress interface, a lookup is conducted using the 5-tuple (source IP, source port, destination IP, destination port, and 'VRF ID on which the packet was received') to determine if there is an existing SCTP association present in the kernel.

• Outbound SCTP packets over VRF:

  For every SCTP packet that is sent out from the kernel, the corresponding VRF ID is obtained from the association data using the 5-tuple (source IP, source port, destination IP, destination port, and 'VRF ID on which the packet is to be sent').

SCTP One‑to‑Many Style Socket

SCTP supports two socket styles: 1 to 1 (comparable to TCP) and 1 to many (allowing multiple active associations on a single socket). The latter facilitates communication with several peer endpoints simultaneously, using association identifiers (assoc-id) to distinguish between them.

The following system APIs are used by the application avail the SCTP 1:1 or 1:n style socket:

System Calls for 1 to 1 Style Socket

• Server role: socket(), bind(), listen(), accept(), write()/read(), close()

• Client role: socket(), connect(), write()/read(), close()

System Calls for 1 to Many Style Socket

• Server role: socket(), bind(), listen(), recvmsg(), sendmsg(), close()

• Client role: socket(), sendmsg(), recvmsg(), close()

Common Header Section

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

Data Chunk Section

This section occupies the remaining portion of the packet. The data chunk fields section describes the fields in the data chunk section.

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