SCTP (Stream Control Transmission Protocol) — Tài liệu chi tiết

Giao thức tầng transport, IP protocol number 132, ngang hàng với TCP và UDP. Chuẩn: RFC 4960 (gốc RFC 2960), hợp nhất lại trong RFC 9260 (2022). Là nền móng của toàn bộ SIGTRAN và các giao diện báo hiệu 4G/5G (S1-AP, NGAP).

1. Vì sao có SCTP — nó lấp chỗ trống nào giữa TCP và UDP

Hai tính năng “đắt giá” với telecom:

• Multi-homing → carrier-grade redundancy: một đầu cuối gắn nhiều IP, một đường chết vẫn không đứt phiên.
• Multi-streaming → mỗi giao dịch báo hiệu đi trên một stream độc lập; một message rớt không chặn message khác.

Đó là lý do 3GPP chọn SCTP cho S1-AP và NGAP thay vì TCP.

2. Khái niệm cốt lõi: Association (không gọi là “connection”)

Quan hệ giữa 2 SCTP endpoint gọi là association. Khác biệt quan trọng so với TCP:

• Một endpoint = tập hợp nhiều địa chỉ IP + một port. Ví dụ: endpoint A = {10.0.0.1, 10.0.1.1} : 2905.
• Một association bao trùm tất cả các đường (path) giữa các IP của hai bên — chỉ cần một association duy nhất, không phải mỗi IP một kết nối.

        Host A                                Host Z
   ┌──────────────┐                      ┌──────────────┐
   │ IP A1 ───────┼─── path 1 (primary) ─┼──► IP Z1     │
   │              │                      │              │
   │ IP A2 ───────┼─── path 2 (backup) ──┼──► IP Z2     │
   └──────────────┘                      └──────────────┘
          └─────────── MỘT association duy nhất ─────────┘

   HEARTBEAT giám sát các path nhàn rỗi / backup.
   Path 1 chết → tự động failover sang path 2, association KHÔNG đứt.

3. Bắt tay 4 bước — “cách 2 server SCTP kết nối”

TCP bắt tay 3 bước; SCTP bắt tay 4 bước để chống SYN-flood. Mấu chốt: server không cấp phát state (TCB) cho tới bước thứ 3.

   Endpoint A (initiator)                 Endpoint Z (responder)
        │                                       │
        │ ───────────── INIT ─────────────────► │  Initiate Tag = Ta, a_rwnd,
        │   V-Tag = 0 trong common header        │  #OS/#MIS streams, Initial TSN,
        │                                       │  DANH SÁCH IP của A
        │                                       │  ⚠ Z KHÔNG tạo TCB, KHÔNG cấp RAM
        │                                       │
        │ ◄──────────── INIT-ACK ────────────── │  Initiate Tag = Tz, a_rwnd,
        │   V-Tag = Ta                          │  STATE COOKIE (đã ký HMAC),
        │                                       │  danh sách IP của Z
        │                                       │
        │ ───────── COOKIE-ECHO ──────────────► │  gửi lại nguyên cookie
        │   V-Tag = Tz                          │  ✔ Z xác thực cookie → MỚI tạo TCB
        │                                       │
        │ ◄───────── COOKIE-ACK ─────────────── │
        │   V-Tag = Ta                          │
        │                                       │
        │ ═══════ ASSOCIATION ESTABLISHED ═════ │

Những điểm cần nắm chắc (hay gặp khi phân tích pcap):

• Verification Tag: mỗi chiều một tag riêng. A chọn Ta (gửi trong INIT), Z chọn Tz (gửi trong INIT-ACK). Sau bắt tay, mọi gói từ A mang Tz, mọi gói từ Z mang Ta. Trong gói INIT đầu tiên, V-Tag ở common header = 0 vì A chưa biết tag của Z. Tag này chống blind injection và gói “lạc” từ phiên cũ.

• State Cookie: một blob tự chứa, được Z ký bằng HMAC với secret riêng của Z, chứa đủ thông tin để dựng lại TCB + timestamp + lifespan. Nhờ vậy Z stateless đến tận COOKIE-ECHO → kẻ tấn công flood INIT không làm cạn RAM của Z. Đây là khác biệt phòng thủ then chốt so với TCP SYN flood.

• Quy tắc bundling: INIT và INIT-ACK không được ghép chung với chunk khác, nhưng COOKIE-ECHO được phép ghép DATA → dữ liệu có thể bắt đầu chảy ngay ở bước 3, không phải chờ bắt tay xong hẳn.

4. Cấu trúc gói: common header + các chunk

Một SCTP packet = 1 common header (12 byte) + 1..N chunk. Một gói có thể “đóng gói chung” (bundling) nhiều chunk nhỏ.

Common header (12 byte):
+--------------------------------+--------------------------------+
|         Source Port (16)       |      Destination Port (16)     |
+--------------------------------+--------------------------------+
|                     Verification Tag (32)                       |
+-----------------------------------------------------------------+
|                       Checksum CRC32c (32)                      |
+-----------------------------------------------------------------+

Mỗi chunk:
+--------+--------+----------------+
| Type   | Flags  | Length (16)    |
+--------+--------+----------------+
| Value (biến đổi theo Type)...    |
+----------------------------------+

Các chunk type chính cần thuộc:

5. Truyền dữ liệu: TSN ≠ SSN, và multi-streaming

Hai bộ số khác nhau, rất hay nhầm:

• TSN (Transmission Sequence Number) — 32-bit, cấp cho mỗi DATA chunk trên toàn association. Dùng cho độ tin cậy (retransmit) và SACK.
• SID (Stream Identifier) + SSN (Stream Sequence Number) — dùng cho thứ tự bên trong từng stream.

Association
 ├─ Stream 0 ─► SSN 0,1,2,3...   (giữ thứ tự độc lập)
 ├─ Stream 1 ─► SSN 0,1,2...     (rớt 1 msg ở đây KHÔNG chặn Stream 0)
 └─ Stream 2 ─► ...

Tất cả DATA chunk — dù ở stream nào — đều dùng chung MỘT dãy TSN để retransmit.

• Bit U (Unordered) trong DATA chunk: gửi message bỏ qua thứ tự.
• SACK mang: Cumulative TSN Ack + a_rwnd + Gap Ack Blocks + Duplicate TSNs — built-in chứ không phải option như TCP SACK.
• Message lớn hơn PMTU được phân mảnh bằng cặp bit B/E (Beginning/Ending).

6. Quản lý path và failover (linh hồn của multi-homing)

Mỗi destination transport address có state riêng: ACTIVE/INACTIVE, error counter, RTO, cwnd, ssthresh — tức congestion control theo từng path.

• HEARTBEAT gửi định kỳ tới path nhàn rỗi (HB.interval mặc định ~30s) để dò khả dụng.
• Path.Max.Retrans (PMR, mặc định 5): lỗi liên tiếp trên một path vượt ngưỡng → path chuyển INACTIVE, traffic dồn sang path khác.
• Association.Max.Retrans (AMR, mặc định 10): tổng lỗi vượt ngưỡng → ABORT cả association.
• Primary path dùng cho DATA mới; khi primary lỗi, retransmit đẩy sang alternate path.

7. Đóng association

Khác TCP, SCTP không có half-close:

A ── SHUTDOWN (kèm cumulative TSN) ──► Z
A ◄──────── SHUTDOWN-ACK ──────────── Z
A ── SHUTDOWN-COMPLETE ─────────────► Z      (đóng êm)

ABORT  → đóng gấp ngay, không đảm bảo flush dữ liệu còn lại

8. SCTP trong telecom — port chuẩn cần nhớ

Đây là chỗ SCTP “lộ diện” nhiều nhất trong hạ tầng (các nhà mạng như Viettel, VNPT, FPT đều chạy SIGTRAN trên SCTP cho liên kết STP–MSC, eNodeB–MME…).

9. Gotcha thực chiến cần lưu ý

• Firewall / NAT không hiểu protocol 132 → drop toàn bộ SCTP. Khi S1-AP/NGAP “không lên” mà thấy INIT đi nhưng không có INIT-ACK về, ~90% là firewall chặn IP protocol 132, hoặc proxy hiểu nhầm checksum CRC32c.
• Lệch a_rwnd hoặc MTU giữa hai bên gây phân mảnh/treo bất thường.
• Multi-homing chỉ hữu ích khi hai path thực sự tách rời về đường vật lý; nếu cả hai IP đi chung một uplink thì redundancy chỉ là giả.

10. Bản đồ học tiếp (gợi ý đào sâu)

Tham chiếu chuẩn

• RFC 9260 — Stream Control Transmission Protocol (bản hợp nhất, 2022)
• RFC 4960 — SCTP (bản trước, vẫn được trích dẫn rộng rãi)
• RFC 3758 — PR-SCTP (Partial Reliability)
• RFC 4895 — Authenticated Chunks for SCTP (AUTH)
• RFC 5061 — Dynamic Address Reconfiguration (ASCONF)
• RFC 8260 — I-DATA chunk (chống head-of-line blocking khi message lớn)
• 3GPP TS 36.412 / 38.412 — S1 / NG signalling transport (SCTP)