Skip to content
LIVE FEED
› SMPP mang OTA — Tài liệu tham chiếu đầy đủ › Kịch bản quét bảo mật SIM bằng SIMTester v2.0.1 › STK, AT Command và luồng OTA cho thiết bị nhúng › Cơ chế OTA SIM (Over-The-Air SIM Management) — Tài liệu kỹ thuật tổng hợp › Tổng Hợp Báo Hiệu SS7 Trong Luồng Xử Lý SMS (MO + OCS & MT) › Luồng SMS qua giao diện SGs (SMS over SGs) — Tài liệu kỹ thuật tổng hợp

BlogABNF — Augmented Backus-Naur Form

3GPPCore NetworkTelecom MusingsTản Mạn Viễn Thông #3GPP #Core Network

Bố cục bài viết

ABNF — Augmented Backus-Naur Form 1. Định nghĩa 2. Bảng ký hiệu 3. ABNF trong Diameter (RFC 6733) Ví dụ thực tế — Subscription-Data (TS 29.272 §7.3.2) 4. Tại sao quan trọng khi phân tích Diameter offensive/CVD 5. Nguồn tham khảo

Trang này

Sunex 29/07/2026 · 3 phút đọc

Ngày tạo

29/07/2026

Cập nhật

Lượt xem

7

Đọc

3m

ABNF — Augmented Backus-Naur Form

1. Định nghĩa

ABNF (Augmented Backus-Naur Form) là một ký pháp (notation) chuẩn dùng để mô tả cú pháp/cấu trúc của định dạng dữ liệu hoặc protocol.

  • Chuẩn hóa chính thức trong RFC 5234 (IETF).
  • Là bản mở rộng của BNF gốc (Backus-Naur Form), thêm các ký hiệu về số lần lặp, khoảng giá trị, v.v. cho dễ đọc/viết hơn.

2. Bảng ký hiệu

Ký hiệuÝ nghĩaSố lần xuất hiện
[ X ]OptionalTối đa 1 lần (0 hoặc 1)
{ X }MandatoryBắt buộc, đúng 1 lần
*[ X ]Optional, lặp lại0 hoặc nhiều lần
1*[ X ]Bắt buộc, lặp lạiÍt nhất 1 lần, có thể nhiều hơn
*n[ X ]Optional, giới hạn trênTối đa n lần
n*[ X ]Optional, giới hạn dướiÍt nhất n lần, không giới hạn trên
n*m[ X ]Optional, giới hạn cả haiTừ n đến m lần

3. ABNF trong Diameter (RFC 6733)

Diameter dùng ABNF để định nghĩa Command Code Format (CCF) — cấu trúc chuẩn cho:

  • Command (ULR/ULA, CIR/CIA, DSR/DSA…)
  • Grouped AVP (Subscription-Data, User-Identifier, Monitoring-Event-Configuration…)

Ví dụ thực tế — Subscription-Data (TS 29.272 §7.3.2)

Subscription-Data ::= <AVP header: 1400 10415>
    [ Subscriber-Status ]
    [ MSISDN ]
    [ A-MSISDN ]
    ...
    [ Trace-Data]
    [ GPRS-Subscription-Data ]
   *[ CSG-Subscription-Data ]
    ...
   *10[ Regional-Subscription-Zone-Code ]
    ...
   *[ Monitoring-Event-Configuration ]
    ...
    [ External-Identifier ]
    [ Active-Time ]
    ...
   *[ AVP ]

Đọc theo bảng ký hiệu ở mục 2:

DòngĐọc là
[ Subscriber-Status ]Optional, tối đa 1 lần
*[ CSG-Subscription-Data ]Optional, lặp lại 0..N lần
*10[ Regional-Subscription-Zone-Code ]Optional, tối đa 10 lần
*[ Monitoring-Event-Configuration ]Optional, lặp lại 0..N lần → mỗi lần là 1 SCEF-Reference-ID khác nhau
[ External-Identifier ]Optional, tối đa 1 lần duy nhất ở vị trí trực tiếp này
*[ AVP ]Extension slot — nhận thêm AVP tùy ý (vendor extension), lặp không giới hạn

Đây chính là cơ sở để xác định: External-Identifier trực tiếp dưới Subscription-Data bị giới hạn 1 lần, nhưng vì nó cũng xuất hiện lồng bên trong Monitoring-Event-Configuration (mà bản thân AVP đó lại lặp được nhiều lần), nên tổng thể 1 bản tin ULA vẫn có thể chứa nhiều occurrence của cùng 1 loại AVP.

4. Tại sao quan trọng khi phân tích Diameter offensive/CVD

  • Xác định giới hạn hợp lệ — biết chính xác AVP nào bắt buộc, AVP nào optional, giới hạn lặp bao nhiêu → phát hiện message malformed/tampered khi capture thực tế không khớp ABNF (ví dụ: DRA tamper thêm AVP vượt giới hạn *10[...], hoặc thiếu Mandatory AVP).
  • Fuzzing target selection — các trường *[ AVP ] (extension slot) là nơi dễ bị lợi dụng để nhét AVP giả mạo mà vẫn pass basic syntax validation, vì ABNF cho phép “bất kỳ AVP nào khác” ở đó.
  • So sánh version/release — ABNF thay đổi giữa các release 3GPP (field mới thêm vào, số lượng lặp thay đổi) → cross-check ABNF đúng release đang test trong lab, tránh áp nhầm rule của release khác.

5. Nguồn tham khảo

  • IETF RFC 5234 — Augmented BNF for Syntax Specifications (ABNF)
  • IETF RFC 6733 — Diameter Base Protocol, định nghĩa Command Code Format (CCF)
  • 3GPP TS 29.272 §7.3.2 — ví dụ Subscription-Data ABNF dùng trong tài liệu này
Contact
Facebook
TOP