External-Identifier AVP — Tổng hợp tham khảo

1. Thông tin cơ bản

Cấu trúc wire-level — AVP đơn giản, không grouped:

AVP Header:
  AVP Code    = 3111
  Vendor-Id   = 10415
  Flags       = V,M
Data:
  UTF8String  = "<Local Identifier>@<Domain Identifier>"

2. Định dạng giá trị (TS 23.003 §19.7.2)

Cấu trúc kiểu NAI (RFC 4282): <Local Identifier>@<Domain Identifier>

• Local Identifier (username part) — operator-managed, dùng để derive/lookup IMSI. Không globally unique một mình.
• Domain Identifier (realm part) — phải là registered Internet domain name (RFC 4282 §4).
• Kết hợp cả hai → globally unique.
• Biến thể group: groupname@realm (External Group Identifier).

3. Mục đích tổng quát

Định danh thay thế IMSI, do operator cấp, để SCS/AS (ứng dụng M2M/IoT bên ngoài mạng) nhận diện và tương tác với UE mà không bao giờ cần biết IMSI thật.

Lợi ích chính:

• Privacy/isolation — IMSI không rời khỏi trust boundary của operator.
• Chịu được IMSI churn — device đổi SIM/IMSI (eSIM swap, roaming re-home) không ảnh hưởng identity phía SCS/AS.
• Group addressing — groupname@realm cho phép trigger/message cả nhóm thiết bị 1 lần.

M2M vs MTC: M2M (Machine-to-Machine) là thuật ngữ ngành chung, chỉ giao tiếp thiết bị-với-thiết bị qua bất kỳ kênh nào. MTC (Machine-Type Communication) là bản 3GPP-hóa của M2M khi chạy qua hạ tầng cellular — chính thức từ Rel-10/11, định nghĩa trong TS 23.682 (kiến trúc) và TS 29.336 (Diameter interfaces). Quan hệ tập hợp: M2M ⊃ MTC.

4. Container: User-Identifier AVP

External-Identifier không đi một mình trên dây — nó luôn được gói trong User-Identifier (grouped AVP), dùng chung cho mọi giao diện MTC/CIoT:

User-Identifier ::= < AVP header >
    [ User-Name ]              -- IMSI
    [ MSISDN ]
    [ External-Identifier ]
    [ Type-Of-External-Identifier ]   -- cá nhân UE hay Group

Quy tắc: chỉ đúng 1 trong 3 (IMSI/MSISDN/External-Identifier) được điền trong 1 request. External-Identifier là giá trị, User-Identifier là cái hộp đựng giá trị đó khi truyền đi trên dây — dùng chung cấu trúc cho mọi giao diện (S6m/S6n, S6t, T6a) thay vì mỗi command tự định nghĩa field riêng.

5. Các giao diện sử dụng

6. Vị trí trong Subscription-Data (S6a/S6d)

Từ ABNF hiện hành (TS 29.272 §7.3.2, Rel-19):

Subscription-Data ::= <AVP header: 1400 10415>
    ...
   *[ AESE-Communication-Pattern ]
   *[ Monitoring-Event-Configuration ]
    [ Emergency-Info ]
    [ V2X-Subscription-Data ]
    [ V2X-Subscription-Data-Nr ]
   *[ eDRX-Cycle-Length ]
    [ External-Identifier ]        <-- vị trí trực tiếp
    [ Active-Time ]
    ...

Có 2 vị trí mang semantics khác nhau:

6.1. Có thể có nhiều External-Identifier trong 1 ULA không?

• Trực tiếp dưới Subscription-Data: KHÔNG — ABNF ghi [ External-Identifier ] (không có *) → cardinality tối đa 1.
• Tổng thể cả ULA: CÓ THỂ — vì *[ Monitoring-Event-Configuration ] lặp lại được nhiều lần (mỗi instance = 1 SCEF-Reference-ID khác nhau), và mỗi instance có thể mang 1 External-Identifier scoped riêng. Ví dụ 1 ULA có 3 Monitoring-Event-Configuration (3 dịch vụ M2M khác nhau) → tối đa 1 default + 3 scoped = 4 occurrence AVP code 3111 trong cùng 1 bản tin.

7. Monitoring Event — “event xảy ra” ở MME là gì

Các loại Monitoring Event mà MME chịu trách nhiệm theo dõi/phát hiện (TS 23.682 §5.6.1, TS 29.336 Monitoring-Type AVP):

Không thuộc MME: “Access Network Congestion Level” và “QoS Notification Control” — do RCAF/PCRF phụ trách.

Monitoring-Type trong Monitoring-Event-Configuration quyết định MME theo dõi loại event nào; khi event đó xảy ra thật, MME mới trigger RIR → SCEF.

8. Xử lý tại MME

1. Feature negotiation — MME phải advertise hỗ trợ qua Feature-List AVP trong ULR; nếu không, HSS không gửi field này, hoặc MME phải bỏ qua im lặng nếu nhận được mà không hiểu.
2. Chỉ cache, không xử lý logic — lưu vào MM context (key theo IMSI), không trigger hành động gì lúc nhận.
3. Áp dụng cho cả 3 cặp command:
   • ULR/ULA — giá trị ban đầu
   • IDR/IDA — update giữa chừng
   • DSR/DSA — xóa (qua Subscription-Data-Deletion flag)
4. Chỉ được dùng khi MME cần report Monitoring Event lên SCEF (RIR) — điền vào User-Identifier.
5. Không có side-effect xuống RAN — không ảnh hưởng S1AP/RRC, bearer setup, paging, QoS. eNodeB hoàn toàn không thấy field này (khác với eDRX-Cycle-Length, Paging-Time-Window — các field CIoT khác có convert xuống S1AP).

9. Luồng tổng hợp

 SCS/AS              SCEF                HSS                 MME
   │                   │                   │                   │
   │                   │                   │◄──── ULR ─────────┤
   │                   │                   │                   │
   │                   │                   ├── ULA ────────────►│
   │                   │                   │  Subscription-Data │
   │                   │                   │  External-Id(default)
   │                   │                   │                   ├─┐ cache
   │                   │                   │                   │◄┘ default/IMSI
   │                   │                   │                   │
   ├── Subscribe ──────►│                   │                   │
   │                   ├──── CIR ─────────►│                   │
   │                   │                   ├──── IDR ──────────►│
   │                   │                   │  Monitoring-Event- │
   │                   │                   │  Configuration     │
   │                   │                   │  SCEF-Ref-ID +     │
   │                   │                   │  External-Id(scoped)
   │                   │                   │                   ├─┐ store
   │                   │                   │                   │◄┘ theo Ref-ID
   │                   │                   │◄──── IDA ──────────┤
   │                   │◄──── CIA ─────────┤                   │
   │                   │                   │                   │
   │  . . . . . . . . . . . . thời gian trôi qua . . . . . . . . .
   │                   │                   │                   │
   │                   │                   │                   ├─┐ event xảy ra
   │                   │                   │                   │◄┘ (bảng mục 7)
   │                   │                   │            ┌──────┴──────┐
   │                   │                   │            │  có scoped? │
   │                   │                   │            └──────┬──────┘
   │                   │                   │        có │       │ không
   │                   │                   │            ▼       ▼
   │                   │                   │      dùng scoped  dùng default
   │                   │                   │      (ưu tiên)    (fallback)
   │                   │                   │            └───┬───┘
   │                   │◄──────── RIR ───────────────────────┤
   │                   │   User-Identifier = External-Id      │
   │◄── Notification ──┤                   │                   │

Mermaid version (import Lucidchart): external_identifier_ula_vs_mec_flow.md

10. Roaming & vị trí SGW/PGW

Traffic có qua SGW/PGW không?

Vấn đề khi roaming:

• S6a (H-HSS ↔ V-MME): piggyback trên session S6a có sẵn cho location update — không cần interconnect mới, thừa hưởng đúng gap đã biết (DRA tampering, không có SEPP-equivalent).
• T6a (V-MME ↔ H-SCEF): đây là interconnect hoàn toàn mới khi roaming — cần roaming agreement + IPX support riêng cho T6a, ngoài S6a/S8/S9 sẵn có. Hệ sinh thái IoT roaming còn non trẻ → có thể fail silent nếu IPX chưa route được T6a.
• Mở rộng structural gap đã có ở S6a/S8 sang T6a — T6a chạy trên Diameter nền cũ (TS 29.128), không có SEPP/PRINS tương đương → External-Identifier ↔ IMSI mapping băng qua biên PLMN 2 lần (ULA + RIR), mỗi lần là 1 điểm exposure độc lập.
• CIoT roaming gần như bắt buộc Home-Routed (giữ HPLMN visibility) — nếu dùng PtP/SGi, traffic đi qua đúng S8, thừa hưởng vấn đề S8 unencrypted đã document.
• Local Breakout càng rối hơn — V-PGW phải forward Non-IP data ngược về H-SCEF qua SGi xuyên PLMN, không phải interconnect chuẩn hóa rõ ràng, rủi ro misconfiguration cao.

11. Tác động lên thuê bao — chỉ M2M hay ảnh hưởng cả dịch vụ khác?

Chỉ ảnh hưởng phần M2M/NIDD/Monitoring, không đụng voice/SMS/data thường, vì:

• Field là optional ([ ... ]), MME/VPLMN không support thì bị bỏ qua im lặng theo nguyên tắc chung Diameter — không reject ULA.
• APN/PDN-Type M2M (Non-IP) hoàn toàn tách biệt khỏi APN voice/data thường — consumer device không tự request PDN Type Non-IP.
• Impact thực tế chỉ xảy ra khi có Monitoring-Event-Configuration/NIDD subscription thật sự active gắn với thuê bao đó.

Nhưng “không ảnh hưởng dịch vụ” ≠ “không có rủi ro”: đây chính là lý do khiến việc lợi dụng field này cho mục đích tracking khó bị phát hiện — user không thấy triệu chứng gì (không rớt cuộc gọi, không mất data) trong khi MME vẫn report reachability/location lên 1 SCEF nào đó ở background. Đây là nhận định bảo mật của người phân tích, không phải fact được 3GPP/vendor nào phát biểu trực tiếp — cần lab-test thực tế để chứng minh.

12. Cân nhắc bảo mật / gap-analysis

• Anomaly trên profile consumer thường — External-Identifier xuất hiện trên 1 subscriber không có dấu hiệu M2M nào khác (APN không thuộc dải IoT, có voice service…) là bất thường, đáng flag: có thể do lỗi provisioning, dịch vụ converged hợp pháp, hoặc dấu hiệu tấn công (attacker gán External-Identifier để mở kênh trigger/monitoring trái phép qua đúng luồng signaling hợp lệ).
• DRA có thể screening được — vì DRA hoạt động như Proxy Agent, có full visibility vào AVP tree lồng sâu. Khả thi: inline inspect Subscription-Data, cross-check với APN/Network-Access-Mode, passive alert trước khi cân nhắc block. Giới hạn: DRA không tự có business context (cần external correlation source), chi phí deep-parse AVP lớn cỡ Subscription-Data (40+ optional field) cao hơn nhiều so với screening nông thông thường.
• Reverse-resolution abuse (ở tầng S6m/S6n) — nếu attacker có IMSI (harvest qua SS7/Diameter), có thể query SIR ngược để lấy External-Identifier nếu HSS không siết authorization theo SCS-Identity — phá vỡ chính mục tiêu privacy-isolation của cơ chế.
• Group enumeration (ở tầng S6t) — cơ chế segment Group-User-Identifier khi group lớn là điểm khai thác tiềm năng nếu authorization scope theo group không chặt.
• Không có integrity binding giữa các giao diện — SIR (S6m/S6n), NIR/NIA (S6t), và ULR/ULA (S6a) độc lập resolve cùng identity space nhưng qua các Diameter session riêng biệt; một DRA/HSS compromised chèn giá trị sai vào Subscription-Data khiến MME report nhầm identity lên SCEF mà không có cách nào tự phát hiện — cùng class lỗi với AVP tampering đã document ở S6a (AMBR/APN-Configuration).
• T6a là interface thứ 3 (sau S6a, S8) đáng đưa vào nhóm “no SEPP-equivalent” — đặc thù riêng: mang chính xác External-Identifier/identity-mapping data, nên nếu bị tamper, hệ quả là identity confusion trực tiếp giữa MME và SCEF, không phải QoS/routing như S6a/S8.

13. Độ tin cậy nguồn — phân biệt fact vs suy luận

14. Nguồn tham khảo

• 3GPP TS 29.336 — Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications (định nghĩa AVP gốc, S6m/S6n/S6t)
• 3GPP TS 29.272 — MME/SGSN–HSS Diameter interfaces (S6a/S6d), §7.3.2 Subscription-Data
• 3GPP TS 23.682 — Architecture enhancements for MTC/CIoT
• 3GPP TS 23.003 §19.7.2 — Định dạng External Identifier
• 3GPP TS 29.230 — AVP code space registry
• 3GPP TS 29.128 — T6a/T6b interface (MME/SGSN ↔ SCEF)
• Cisco StarOS MME Administration Guide — hành vi xử lý thực tế tại MME (precedence rule, Monitoring Event types)